Only give initial and empty loaded about:blank documents the implicit
light/dark supported schemes when they belong to a top-level navigable.
Embedded empty documents should not negotiate the page preferred dark
scheme while their embedding element remains light, since that forces an
opaque dark iframe canvas.
Add text coverage for both initial and navigated embedded about:blank
documents under a dark preferred scheme.
Opt empty about:blank documents into both light and dark supported
color schemes. This covers both navigation-created about:blank documents
and the initial about:blank document created with a browsing context, so
dark mode can choose the dark Canvas color before page content arrives.
Follow the spec reuse of the initial same-origin about:blank window for
a browsing context's first real navigation. This fixes a crash in
promise-job-entry-different-function-realm.html by preserving the
correct iframe realm.
However, reusing the initial about:blank Window means
create-and-initialize can associate that Window with the pending
Document before session history activation has made the Document active.
Treating a browsing context's active document as its active Window's
associated Document therefore exposes the pending Document too early.
To fix this, add an explicit active document slot to BrowsingContext and
update it when a Document is made active.
A similar fix was attempted in 7fc7263a4d,
but that version still queued navigation tasks through the reused active
Window, tagging them with the pending Document before it was active.
This caused parser-created iframe loads to hang in encoding WPTs. This
commit instead queues those navigation-internal tasks against the
navigable's currently active Document.
The newly added iframe-initial-load-chunked-body.html mimics the same
type of failure seen by the WPT regressions mentioned above.
Change the parameters types of the functions `coarsen_time` and
`coarsened_shared_current_time` from `bool` to
`CanUseCrossOriginIsolatedAPIs` for more coherence with the surrounding
code.
The VERIFY() this was triggering wasn't actually to spec, and by the
time it gets encountered, the browsing context isn't technically a top-
level context yet, because it has just been created and the definition
of a top-level browsing context requires the document to be the
navigables active document, which it only becomes once a history entry
has been created for it.
Therefore we cannot just verify a top-level browsing context actually
being a top-level browsing context when inserting it into the group,
because that happens to early in its life-cycle as a top-level context.
This makes it so that JS console commands from the devtools no longer
get sent to the last created nested frame in the tab, because nested
frames no longer pretend to have a top-level browsing context.
Instead, porting over all users to use the newly created
Origin::create_opaque factory function. This also requires porting
over some users of Origin to avoid default construction.
These are not associated with a javascript realm, so to avoid
confusion about which realm these need to be created in, make
all of these objects a GC::Cell, and deal with the fallout.
This is required to store Content Security Policies, as their
Directives are implemented as subclasses with overridden virtual
functions. Thus, they cannot be stored as generic Directive classes, as
it'll lose the ability to call overridden functions when they are
copied.
A couple of reasons:
- Origin's Host (when in the tuple state) can't be null
- There's an "empty host" concept in the spec which is NOT the same as a
null Host, and that was confusing me.
In #1537, determine_the_origin() changed to take
`Optional<URL::URL> const&` as first parameter, but it's passed
`Web::Fetch::Infrastructure::Response::url()`, which returns
`Optional<URL::URL const&>`. Ladybird does not have
SerenityOS/serenity#22870 (yet?), so this mismatch silently creates
a copy.
Change determine_the_origin() to take `Optional<URL::URL const&>`
instead. No behavior change, saves a copy, and is probably what
was originally intended.
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
Now that the heap has no knowledge about a JavaScript realm and is
purely for managing the memory of the heap, it does not make sense
to name this function to say that it is a non-realm variant.
The main motivation behind this is to remove JS specifics of the Realm
from the implementation of the Heap.
As a side effect of this change, this is a bit nicer to read than the
previous approach, and in my opinion, also makes it a little more clear
that this method is specific to a JavaScript Realm.
