- DataTransferItem/DataTransferItemList/Iterator forward acquireRef/releaseRef
to the owning DataTransfer, so its pooled arena outlives any JS-held wrapper
(fixes a potential use-after-free when JS keeps an item/list/iterator alive
past the DataTransfer).
- addItem reads strings straight into the persistent arena via
toStringSliceWithAlloc, removing the intermediate call_arena copy.
- normalizeFormat uses std.ascii.allocLowerString instead of dupe + lowerString.
- setData: rename dup -> owned_data for clarity.
DragEvent extends MouseEvent (new drag_event arm in the MouseEvent type union)
and exposes a nullable dataTransfer, so JS can build a DataTransfer and dispatch
a drop/dragover event whose .dataTransfer.files is readable. Also resolves the
InputEvent dataTransfer TODO with a real field + accessor.
Both events hold a refcount on the DataTransfer for their lifetime and release
it in deinit (via the leaf acquireRef/releaseRef/deinit trio, like MessageEvent
holds a Blob), so the store's arena can't be freed out from under an event whose
JS wrapper is collected first.
Refs #2043
Implements the constructible DataTransfer interface and its item views over a
single drag-data-store: string- and file-kind items, with .files (FileList) and
.types derived from the file items so items.add(file) is visible immediately.
File refs are acquired on add and released on remove/clear; the backing FileList
is frame-tracked and the DataTransfer arena is refcounted so the GC finalizer
reclaims it, leaving no leaks.
Refs #2043
Address review: replace the bare 0/1/2 button values in the
mousedown/release switch (Frame.zig) and the CDP button mapping
(input.zig) with named constants so the code self-documents.
Element.scrollIntoView and scrollIntoViewIfNeeded were no-op stubs.
Implement them to scroll the window so the element's position is
brought into the viewport, using the element's document position (the
same source getBoundingClientRect uses) and Window.scrollTo.
This lets automation reach below-the-fold elements before interacting
with them.
Input.dispatchMouseEvent ignored the button and clickCount params, and
mousePressed only fired a click event (never mousedown). Add them:
- mousePressed now fires mousedown carrying the pressed button.
- mouseReleased fires mouseup, then the button-appropriate activation
event: click for the main button, auxclick for the auxiliary button,
and contextmenu for the secondary (right) button.
- a clickCount of 2 additionally fires dblclick.
This unblocks right-click, middle-click and double-click interactions
for Playwright/Puppeteer scripts. Follows the mouse event work in
#2636, #2640 and #2641.
Passes WPT /html/webappapis/atob/base64.html
Two changes
1 - Use the forgiving decoder already in data_url
2 - Coerce input (3 => "3")
The 2nd change was more interesting. These take a js.String.OneByte as an
optimization, which doesn't coerce. To preserve this optimization a union was
used with a `raw: []const u8` fallback (and our bridge always coerces to
a `[]const u8`)
collectForm now emits File entries for <input type="file"> (one per
selected file, or a synthetic empty File with application/octet-stream
when none is selected, per WHATWG). multipartEncodeEntry writes the
filename, Content-Type, and file bytes per RFC 7578; Value.asString /
format fall back to the filename for urlencoded / text-plain encodings.
Just a random test I happen to see in WPT, 0/99 -> 99/99:
/html/semantics/scripting-1/the-script-element/json-module/invalid-content-type.any.worker.html
This limit isn't about correctness,it's just about making sure a test doesn't
block forever. 2 seconds does seem like plenty of time, but I'm thinking it's a
slow/busy CI. If it still happens after this bump, could mean there's an actual
issue.
