As we've seen before, both document.write and custom elements callbacks can
introduce otherwise impossible states. See https://github.com/lightpanda-io/browser/pull/2172
for just one example.
The issue with both is that they can trigger code during DOM manipulation that
renders the state of that DOM manipulation invalid. This commit started with
a fairly easy case to understand (one that actually happened in production). It
goes something like:
```
<div id=x>
<script>
document.write('<script>x.innerHTML = "";</script>');
</script>
</div>
```
Here we see that the written script deletes the node which is in the process
of being rendered.
These issues are almost always easy to fix, but they're hard to predict. After
fixing this issue, I asked Claude to check for other cases, and it was able to
find / reproduce / fix two more involving custom elements callback.
Address review feedback on the legacy KeyboardEvent.keyCode and
KeyboardEvent.charCode getters:
* `getKeyCode` and `getCharCode` now early-return 0 when the event is
not trusted, matching Chrome's behavior. Synthetic events created via
`new KeyboardEvent(...)` from script have `isTrusted === false` and
therefore expose 0 for both legacy attributes; only events dispatched
by the user agent itself surface the legacy mapping.
* `getCharCode` now uses `_type_string.eql(comptime .wrap("keypress"))`
to match the idiom used elsewhere in the project.
* The charCode mapping is moved into a pure `Key.charCode()` helper that
mirrors `Key.keyCode()`, including a `.Enter => 13` arm so a trusted
`keypress` for Enter exposes `\r` (U+000D) per spec.
The JS test fixture is consolidated into a single block asserting the
Chrome-correct behavior for synthetic events. The full per-key mapping
table is now exercised via two pure-function Zig unit tests on
`Key.keyCode()` and `Key.charCode()`.
Both getters were stubs returning 0. Per W3C UI Events § Annex C, keyCode
should report the legacy fixed virtual key code for the key being pressed
(e.g. 84 for 't'/'T', 16 for Shift, 13 for Enter), and charCode should
report the Unicode code point of the character produced on keypress events.
Adds a keyCode() method to the Key union that maps each named variant to
its spec-defined value and computes the uppercase-ASCII fallback for
.standard printable characters. getKeyCode delegates to it. getCharCode
checks the event type and returns the first byte of _key.standard for
keypress, 0 elsewhere.
For shift-modified symbol keys (e.g. shift+1='!'), keyCode falls back to
the modified char's ASCII rather than the unmodified key's value, since
KeyboardEvent doesn't currently store the unmodified key. Spec-strict
behavior would need plumbing unmodifiedText through KeyboardEventOptions
— left as a follow-up.
Closes#2291
