Was reviewing https://github.com/lightpanda-io/browser/pull/2836 and realized
the StyleManager's getInlineStyleProperty could be optimized to avoid creating
the CSSStyleProperties in the case where there's no style attribute.
Frame.loadExternalStylesheet fetches an external <link rel=stylesheet>
synchronously, which registers a blocking request for the frame. While that
blocking request is active the DeferringLayer holds back the completion
callbacks of every other in-flight transfer for the frame, so they don't run
JS on the parser stack. The blocking-<script> path and the worker path flush
those deferred completions once their synchronous fetch returns, but the
external-stylesheet path did not. As a result a <script defer> that finished
loading during the stylesheet's blocking window stayed at complete == false:
the deferred-script queue never drained, so the deferred scripts never ran and
DOMContentLoaded / the load event / readyState -> "complete" never fired —
the document was stuck at readyState "loading" even though every request
completed with HTTP 200.
Flush the frame's deferring layer after the synchronous stylesheet fetch,
mirroring the other two synchronous-request call sites.
Closes#2842
getComputedStyle now reads inline values from the element's parsed
el.style through StyleManager.inlineStyleValue instead of re-parsing the
style= attribute, so computed and inline values share one source of
truth. Move the !important cascade precedence to the shared parse path
(applyParsedDeclaration) so el.style resolves duplicate declarations
correctly too.
Per spec, this should be accessible on the Document, not the HTMLDocument. I
ran into a site that was doing:
Object.getOwnPropertyDescriptor(Document.prototype, "cookie")
and that was failing
Changes `page.goto` to return a pending Promise instead of blocking
synchronously. Introduces a driver loop in `Runtime` to tick the
browser and settle pending navigations. This allows parallel gotos
and routes tool calls to their respective frames.
Nothing major, but the feature that caught my eye was the addition of a
threadpool for DNS resolution, rather than a thread-per-resolution (1). I've
enabled it.
(1) 39036c9021
This builds on top of 995efd57e6. That commit
tracked the number of requests being made on a single XHR instance (because a
new request can be initiated from a load/error callback of an existing one).
However, that was unbound. It wasn't just 1 old + 1 new, it was an unlimited
number of new requests, because we didn't prevent sending while sending was
already active.
This adds a boolean to track our send state, and prevents a send from happening
when a send is already active.
MessageEvent.getSource returned the bare *Window, the only window accessor
that did not go through Window.Access.init. Every other accessor
(iframe.contentWindow, window.parent, window.top) wraps a cross-origin target
as *CrossOriginWindow. JS object identity is keyed by Zig pointer
(identity_map), so cross-origin event.source (the *Window) and
iframe.contentWindow (&window._cross_origin_wrapper) resolved to different JS
objects: `event.source === iframe.contentWindow` was false cross-origin while
true same-origin.
The WHATWG HTML spec requires these to be the same object regardless of origin
(one WindowProxy per browsing context; MessageEvent.source is that
WindowProxy). The mismatch breaks postMessage handshakes that authenticate the
sender by reference identity, e.g. keycloak-js's 3rd-party-cookie check
(`if (iframe.contentWindow !== event.source) return;`), which then times out
and fails OIDC init.
Route getSource through Window.Access.init(frame.window, source) — exactly like
IFrame.getContentWindow — so both paths resolve to the same per-frame proxy.
Same-origin behaviour is unchanged. Verified against Chrome 149 (identity holds
cross- and same-origin). Adds a regression test, cross_origin_message_source.html.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
frameChildFrameCreated emitted Page.frameAttached with its payload wrapped
in an extra `.{ .params = ... }`. CDP.sendEvent already places the payload
into the event's `params` field, so this produced a malformed wire event
with double-nested params (`params.params.frameId`) — unlike every sibling
frame event in the same function, which passes its fields flat.
CDP clients (e.g. Playwright via connectOverCDP + page.route) parse
frameId/parentFrameId at the top level of params. With the fields one level
too deep the client never registers the child frame, so when that frame's
Fetch.requestPaused arrives it is bare-continued instead of matched against
a route. The result: request interception (page.route / Fetch) silently does
not apply to iframe (sub-frame) document navigations — the iframe loads from
the real network. The interception layer itself was never at fault; it does
emit requestPaused for sub-frames.
Drop the extra wrapper so the payload is flat. Add a regression test that
dispatches frame_child_frame_created and asserts Page.frameAttached carries
frameId/parentFrameId directly under params (fails on the double-nested shape).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The parsing behavior of HTML depends on what we're parsing it for. innerHTML on
a script is parsed (slightly) differently than for, say, the body. html5ever
supports this, we just have to give it the tag name (which we have access to
in the html5ever bridge already).
Also, extend the tag types that dump does NOT escape for beyond noscript/script.
Fixes warnings with some NextJS sites
This causes some feature detection (jquery/amazon) to think we're some old
version of IE, which then requires IE-specific APIs. It sets a ".55" value and
then reads it, expecting 0.55.
This is a noop implementation of navigator.sendBeacon. It often shows up in the
logs. I believe that returning "true" to signal successful queuing is correct
as it'll prevent any attempts to fallback. However, I'm less sure that noop'ing
the entire thing is better than just implementing it.
