Implement support for beforeinput event

[danielkov]

Adds an onbeforeinput event handler that fires before an editable element is about to be modified. Unlike oninput, the event is cancellable: handlers can call event.prevent_default() to block the user agent from applying the change. Exposes input_type, data, is_composing, and the pre-change value.

What changed

• BeforeInputData / HasBeforeInputData / SerializedBeforeInputData in dioxus-html.
• convert_before_input_data plumbing in dioxus-desktop, dioxus-liveview, dioxus-native-dom (unimplemented stub), and dioxus-web (WebBeforeInputData reads value from <input>, <textarea>, <select>, or textContent).
• JS serializer: emits input_type, is_composing, data only when event.type === "beforeinput", so existing oninput payloads are unchanged.
• Headless tests covering plain <input>, IME composition (isComposing: true, non-ASCII data), and contenteditable <div>.
• event_bubbles("beforeinput") => true to match the DOM spec.

Design decisions

input_type is required (not #[serde(default)]). EventData is an #[serde(untagged)] enum, so its derived Deserialize falls through variant-by-variant.

Reason: every existing variant has all-default fields and no deny_unknown_fields. Direct EventData::deserialize call matches the first variant by shape and silently drops the rest of the payload. This is existing behaviour. I filed an issue separately (#5582) and happy to move onto it next. Requiring input_type ties the BeforeInput variant to a field the browser always emits for InputEvent, so it acts as a discriminator. The happy path through HtmlEvent::deserialize routes by event name and never depends on this, but the public derived impl is now harder to misuse.

Drive-by textContent fallback in serializeInputEvent. Previously, calling event.value() from any input-shape handler (oninput, onchange, now onbeforeinput)

Previously returned "" on desktop/liveview for contenteditable elements, even though dioxus-web returned textContent via WebFormData::value / WebBeforeInputData::value. The JS serializer now mirrors the wasm renderer: if the target isn't an <input>/<textarea>/<select> but is an HTMLElement, contents.value falls back to target.textContent ?? "", yielding the same result regardless of renderer. This affects input, change, submit, reset, click, and beforeinput payloads on contenteditable targets. Happy to split this into a follow-up if you prefer.

Docs

The onbeforeinput rustdoc has a runnable example showing how to block digit insertion. Uses event.data.input_type() / event.data.data().

References

• Closes beforeinput event missing #4822
• Tracked in Tracking: missing/incomplete HTML events #5092

[ealmloff]

Thanks for picking this up! Overall looks good, but there is a bit of duplication around the input data and we could represent the types better for the input_type method

[ealmloff]

It would also be great to get this added to the all_events example we use for smoke testing events before a release

[ealmloff]

Thanks, looks great!

[ealmloff]

min dep failure in ci is unrelated. see #5609