Mutable tags like @v6 can be re-pointed by whoever controls the action,
so the next run executes code nobody here reviewed, with the job's
token and secrets. Pinning to the full commit sha freezes what runs.
Version tags are kept as comments so renovate or dependabot can still
track updates.
dtolnay/rust-toolchain is pinned to a master commit with the toolchain
moved to an explicit input, as its readme recommends for sha pinning.
Normalize get name so that it matches the normalize stored cookie name.
Don't queue cookie change event if there's no listener. This one's a bit tricky
since we do this check inside the callback already. But that means a listener
added after the event is created (but before it's delivered) gets a change
event it should not. So we need to check it both at event-creation time and
at delivery time.
This applies two individual fixes to our robots.txt parser. The first is that
instead of doing an exact match with the User-Agent, it extracts the
"productToken". A UA of Lightpanda/1.0, should match "Lightpanda". The second is
that an empty directive matches.
Given:
User-agent: Lightpanda
Disallow:
User-agent: *
Disallow: /
We would have failed for 2 reasons. Fix#1 is necessary, otherwise
"Lightpanda" != "Lightpanda/1.0". Fix#2 is necessary because this robots.txt
does _not_ disallow Lightpanda from anything (e.g. the fallback doesn't apply
to us).
This reworks blob URLs from being owned by the Frame to being owned by the Page
and shared / protected by origin. This allows, for example, a worker/popup/
iframe from accessing blobs created by its page, provided they share the same
origin.
This was already working on a small (but common) set of cases, but has now been
reworked (by moving the blob registry up to the Page, where it can be shared) to
cover every case.
Polling delays processing of messages. So don't poll after we know we've
dispatched. Largely impacts CDP which is more likely to poll (for data on the
CDP connection).
Spec says this is what we should do and it's apparently used a part of bot
detections (because bots don't load about:blank and thus the iframe's state
can easily be checked to be invalid, I guess).
The idea is that, for most cases, the top level page isn't revisited, so
caching is just overhead + wasted space. Plus, if someone does revisit it,
chances are they want a fresh copy.
Imagine someone scraping a typical ecommerce site. Sure, they want to cache
the .js files which get re-used from product to product. But do they want to
cache each individual product page?
The disposed entries are already out of _entries, so an error during
the currententrychange dispatch leaked their _on_dispose callbacks
(onRemoveFrame only walks _entries). Fire dispose in a defer and log
per-entry failures instead of propagating them.
Builds ontop of https://github.com/lightpanda-io/browser/pull/2719 and adds
the missing layer-priority.
This can be broken down into two parts. The first is the hot read path. This
code is unchanged...same buckets and same u64 priority comparison.
What has changed is the build/rebuild step and how / what the
VisibilityRule.priority means. priority used to be 32bits for specificity and
32bits for doc order (specificity tie-breaker). Priority is now 12bits for
layer rank, 30bits for specificity and 22bits for doc order. Specificity was
only using 30bits, and the smaller doc order means we can now only represent
4 million rules (Facebook, which has _a lot_ of rules, has ~50K and like 95% of
those are not visibility rules..so we have plenty of space still).
But layer ordering is complicated because you need to parse everything before
you know the final order. So our build now accumulates intermediary results and
does a final iteration through the VisibilityRule to |= the rank_layer bits of
their priority. This is no-op if there are no layers (common case for now).
Because of this intermediary work, I've added a build_arena that is build/
rebuild specific. Possibly overkill since we don't expect sites to have
thousands of layers, but it's cheap to add (except now you need to think: should
I use the build_arena or self.arena).
std.start.maybeIgnoreSigpipe() already installs a noop SIGPIPE handler
at startup (std.options.keep_sigpipe defaults to false), so a write to
a dead pager returns error.BrokenPipe — which the existing catch
handles — instead of killing the process. The manual SIG_IGN was also
the disposition std deliberately avoids, since ignored dispositions
survive exec and would leak to child processes.
Use the call arena only for the AbortSignal dependent list that must survive re-entrant abort handlers, and move scratch-only DOM reads to the local arena. Store BeforeUnloadEvent.returnValue in the event-owned arena so it remains valid without accumulating in the longer-lived frame arena.
These allocator changes bound temporary memory to the shortest safe lifetime while preserving existing Web API behavior. Add coverage for replacing BeforeUnloadEvent.returnValue.
Keep one slab-allocated scheduler task per active element scroll sequence and recycle it on completion or scheduler cancellation. This prevents repeated programmatic scrolling from growing the frame arena and task queue without bound.
Advance the throttle state before dispatching scroll and scrollend so nested JavaScript callbacks cannot be overwritten, and avoid scheduling events for clamped no-op scrollBy calls. Add coverage for coalescing, both re-entrant event paths, and no-op scrolling.
Review pattern from #2943: prefer the local arena for scratch-only
allocations. scheduleNavigation dupes the URL into its own arena
synchronously at entry, so the normalized fragment does not need to
survive the call.
Co-Authored-By: Karl Seguin <karlseguin@users.noreply.github.com>
After rebasing onto main, WPT
/dom/events/Event-dispatch-single-activation-behavior.html went from
3/132 to 0/0 (harness never reported): the test repeatedly clicks
`<a href="#link">` anchors and resets with `location.hash = ""`, and
both patterns ended up scheduling full same-URL reloads, putting the
page in a reload loop. As with the previous commit, the pre-rebase
code masked this because queued navigations rarely executed; the
HttpClient refactor made them reliable.
Two fixes, per the HTML navigate steps (a navigation is a fragment
navigation when the URL equals the document's URL excluding fragments
and its fragment is non-null) and the Location hash setter (if the
fragment doesn't change, no navigation happens):
- Frame.scheduleNavigationWithArena: re-navigating to the exact
current URL is only a reload when the URL has no fragment. With a
fragment (e.g. re-clicking the same `#link` anchor) it's now a
no-op fragment navigation: no reload, and since the fragment didn't
change, no hashchange and no history entry. Upstream's "identical
URL reloads" behavior (iframe.src = "about:blank" twice) is
untouched — those URLs carry no fragment.
- Location.setHash: skip the navigation entirely when the normalized
fragment equals the current one, so `location.hash = ""` on a
fragment-less URL (and re-assigning the current fragment) no longer
schedules a same-URL reload. Assigning "" still strips the fragment
from the URL, matching the existing tests/window/location.html
expectations.
Unit test added in tests/window/location.html: href stays stable
across repeated `hash = ""` and same-fragment re-assignments.
Coverage: /dom/events/Event-dispatch-single-activation-behavior.html
0/0 -> 83/132 (3/132 before the rebase; the gain past 3 comes from
the handler-return-value fix in the previous commit).
After rebasing onto main (HttpClient refactor: queued navigations now
reliably execute), WPT /dom/events/Event-dispatch-click.html went from
33/33 to 0/0: its form subtests cancel submission with
`form.onsubmit = () => { ...; return false }`, but the inline-handler
invocation discarded the return value, so the form really submitted,
the scheduled form navigation reloaded the page in a loop and the
harness never reported. Before the refactor the queued navigation
never ran, which masked the missing behavior.
Per the HTML "event handler processing algorithm" (§8.1.8.1, "Process
the return value"), an event handler attached via an on* property or
attribute that returns exactly false cancels the event — unlike
addEventListener listeners, whose return value is ignored. The
inverted onerror special case only applies to the global's onerror,
which is invoked via Window.reportError, not through node dispatch.
Implementation: the two inline-handler invocation sites in
EventManager.dispatchNode (at-target and bubble phase) now call the
handler with a js.Value return type and route it through a new
processHandlerReturnValue helper, which calls event.preventDefault()
when the returned value is strictly false (skipping "error" events).
Unit test added in tests/events.html covering: at-target handler,
ancestor (bubble-phase) handler, other falsy return values not
canceling, and addEventListener return values staying ignored.
Coverage: /dom/events/Event-dispatch-click.html 0/0 -> 33/33
(restores the previously claimed 33/33); also a prerequisite for
/dom/events/Event-dispatch-single-activation-behavior.html (see next
commit).
