Treat a scoped `@import` rule as a scope descriptor while traversing
style-producing rules from imported stylesheets. Imported rules now
inherit an outer scope for unscoped imports and replace it when the
import itself carries scope(...).
Scope resolution was generalized to handle both CSSScopeRule and
CSSImportRule descriptors. Import-scope boundaries are matched using
the stylesheet that parsed the `@import` rule, while normal imported
selectors keep using the imported stylesheet context. This lets
implicit scopes, nested `@scope` rules, :scope, and top-level `&` behave
as the Cascade 6 model requires.
Parse and store the optional `scope` clause in `@import` preludes.
WPT doesn't directly test the serialization behaviour for this, so add a
custom test for it.
Problem: Ref/input/css/images-load-relative-to-imported-style-sheet.html
intermittently fails on the Linux Sanitizer with a deterministic 398px
screenshot mismatch — the entire 20x20 background- image div is
unpainted in the test pass, while the reference paints the checkerboard.
Cause: CSSImportRule::fetch() added to the document’s render-blocking
set (m_pending_css_import_rules) — but didn’t delay the load event. The
load event could fire before the imported stylesheet had finished
fetching — so the background image referenced from inside that sheet
hadn’t even been requested yet when test-web’s on_load_finish callback
ran wait_for_reftest_completion and proceeded to take the screenshot. By
contrast, <link rel="stylesheet"> already delays the load event for its
own duration via m_document_load_event_delayer in HTMLLinkElement —
which is why the sibling test using <link> doesn’t flake.
Fix: Hold a DocumentLoadEventDelayer in CSSImportRule for the duration
of the import fetch, paralleling HTMLLinkElement. By the time the import
rule’s delayer clears in the ScopeGuard, the imported sheet’s image
fetches have already been kicked off via SharedResourceRequest, each of
which takes over load-event delaying through its own delayer — so
there’s no race between the two delayers releasing.
Previously, `<link rel=stylesheet>` would delay the load event until its
style sheet loaded, but not care about its subresources. `<style>`
would not delay the load event at all. Instead, each `@import` would
delay the load event.
Now, both `<style>` and `<link>` delay the load event until their style
sheet and its critical subresources have loaded or failed. This means
that CSSImportRules no longer need to delay the load event themselves,
because they do so implicitly as a critical subresource of their parent
style sheet.
This doesn't directly affect behavior, but means that any other critical
style resources we add will automatically delay the load event.
One wrinkle here is that the spec for the `<link>` element requires that
we wait for the style sheet's critical subresources *before* we create
a CSSStyleSheet, which means we don't yet know what those are.
https://html.spec.whatwg.org/multipage/semantics.html#fetching-and-processing-a-resource-from-a-link-element:critical-subresources
For now we simply ignore this, as we did before. That means we continue
to not delay the `<link>`'s load event.
Previously, we fired the load event immediately, without waiting for
anything. This was good for not timing out, but bad for anything that
wanted to wait for the load to complete.
CSSStyleSheet now maintains a list of critical subresources, and waits
for all of them to complete before it then tells its owner that it is
ready. "Complete" here means the network request completed with or
without an error. This is done by having those subresources (just
`@import` for now) notify their style sheet when they complete. This
then propagates up as an `@import` tells its style sheet, which then
would tell its parent `@import` if it had one.
There are other subresources we should wait for (specifically fonts and
background images) but this commit just adds `@import` as a first step.
Specifically, we create and assign a layer if its import conditions
currently apply.
With this change, every case in the `layer-import.html` test actually
functions correctly, apart from our lack of proper `load` event
support. (Tested by hacking in a 100ms wait after the `await Promise()`
statement.)
...instead of returning the one from its associated style sheet.
This reverts 848a250b29 where I made
`CSSImportRule.media` nullable.
CSSImportRule may not have an associated style sheet, because of not
matching a supports condition, or just failing to load the URL.
Regardless of whether we do or not, the expected (non-spec) behaviour
is that we should return a MediaList always, which matches the media
queries specified on the `@import` rule.
Having the dumping code in a separate Dump.cpp meant that it was often
overlooked when the rules gained new features, and also limits dumping
to publicly-accessible information.
The recent commits 28ba610f32 and
70c4ed261f adjusted some include
directives to avoid excessive recompilation when changing some header
files. This has broken compilation with clang-cl on Windows without
getting noticed before the PRs were merged.
The regression in the "conditional-CSSGroupingRule" test is we now fail
the "inserting an `@import`" subtests differently and the subtests
aren't independent. Specifically, we don't yet implement the checks in
`CSSRuleList::insert_a_css_rule()` that reject certain rules from being
inserted. Previously we didn't insert the `@import` rule because we
failed to parse its relative URL. Now we parse it correctly, we end up
inserting it.
It's possible to parse an `@import` rule that isn't attached to a
document. We only actually need it to have one when fetching the linked
style sheet, and that should only happen when the CSSImportRule is
attached to a document. So, we can just accept a null pointer when
constructing it.
We relied on that Document to get the Realm, so pass that in as a
separate parameter.
To prepare for introducing a CSS::URL type, we need to qualify any use
of LibURL as `::URL::foo` instead of `URL::foo` so the compiler doesn't
get confused.
Many of these uses will be replaced, but I don't want to mix this in
with what will likely already be a large change.
Resulting in a massive rename across almost everywhere! Alongside the
namespace change, we now have the following names:
* JS::NonnullGCPtr -> GC::Ref
* JS::GCPtr -> GC::Ptr
* JS::HeapFunction -> GC::Function
* JS::CellImpl -> GC::Cell
* JS::Handle -> GC::Root
