Troubleshooting

Problems, and how to recognise them

Most surprises on the HTML path come from what is not built yet, and most on the widget path from the text input rules. Each section says which case you are in and why it behaves that way.

An HTML app opens no window

This is expected today. HtmlDom runs the app, lays it out and returns a display list and a plan, and nothing hands the plan to the renderer yet (#43). Check your screen by its layout instead: print the entries, or test them the way the examples do.

A click or a change does not show

Handlers run inside click, input and the other calls, and the document changes only when you call render. The display list changes only on the next layout. So the order is always: the call, render, layout.

dom.click(x, y);
dom.render();
dom.layout(800.0, 600.0, 1.0);

click returns None when nothing under the point listens, which is also what happens when the point is outside a clipping ancestor, or under a box with a higher z-index. hit_test(x, y) tells you which node is there.

Typing does not update the page

Fields are uncontrolled on purpose: the renderer owns their text, and committed text reaches oninput. The page changes only if your handler writes a signal that something renders from, as samples/chat does with its draft. See Fields are uncontrolled.

Text is a different size than in a browser

Without a measurer of your own, text is measured by Parley, and Parley's sizes differ from Chromium's on macOS by enough to move line breaks. Mixed-font paragraphs, table cells and form controls are measured by Parley even when you supply a measurer. Measuring with Compose is partial (#43). Box layout itself matches VS Code to within 1px when the text sizes match.

An image draws nothing or has no size

There is no ImageResolver, or it answered None. Nothing is ever fetched, so an image the resolver does not know draws nothing.
An <img> with no width or height takes its size from the resolver's size. Without that answer it has no natural size.
The URL is not the one you expected. Relative URLs are resolved against HtmlConfig::base_url, or passed as written when there is none. Log what your resolver is asked.

A CSS feature has no effect

rotate, scale, skew, matrix() and transform-origin are not drawn; translate is (#46).
Transitions and animations do not play (#46, #47).
A <script> does nothing, by design. Behaviour is written in Rust.
The user-agent stylesheet gives body an 8px margin, as a browser's does. The examples start their stylesheets with body { margin: 0; }.

The build cannot get the renderer

The renderer is a prebuilt native library, downloaded for your target by compose-rust's build script and checked against its published checksum. When that fails, the build says what it tried. Building with no network, using a renderer you built yourself, and moving the download cache are covered in compose-rust's README.

IME problems on the widget path

Enter submits and the syllable is lost. You type Korean, press Enter to commit the syllable, and the message is sent without it. Key events reached Rust during composition, which the renderer must never allow. That is a renderer bug, not a problem in your handler.

Composition resets as you type. Characters vanish or reorder while a syllable is being built. Something set the field's text from Rust during composition. TextField has no value for exactly this reason; clear a field by giving it a new identity.

ProtocolError events

A widget, property or modifier the renderer does not recognise does not crash anything. The renderer sends a ProtocolError event with a code and a message. It means the two halves disagree about the schema, normally a renderer from a different compose-rust version than the one your build links. A larger mismatch is caught earlier: the schema hash is compared at start-up, and the two halves refuse to run together.