Elements with transforms were tested on their pre-transformed
positions, causing incorrect hits.
Copy the position transformation done in `StackingContext::hit_test`
to ensure that hit tests are done on the _actual_ position.
For Qt >= 6.5, the system theme can be determined reliably, so no
guesswork is needed. A fallback remains for Qt < 6.5, but it is
hacky and less reliable.
If we reach the insertion point at the same time as we switch to another
tokenizer state, we have to bail immediately without proceeding with the
next code point. Otherwise we'd fetch the next token, get an EOF marker,
and then proceed as if we're at the end of the input stream, even though
more data may be coming (with more calls to document.write()..)
The repository being in static storage is a bit of a hodgepodge, but in
line with how our current storage partitioning is done. We should
eventually move this, along with other across browsing context APIs to a
proper location at a later stage. But for now, this makes progress on
the meat of the BroadcastChannel API.
In the case where we had a preferred aspect ratio and a natural height
but no natural width, we'd get into ping-ponging infinite recursion by
trying to find the width to resolve the height to resolve the width to
resolve the height...
These fields are modified by an invocation to CalendarResolveFields. All
callers currently don't care about these modifications, so they move the
CalendarFields struct into the AO. But it turns out that at least one AO
will care (InterpretTemporalDateTimeFields), thus we will need to take
by reference here.
Currently, AbstractOperations.h needs to include Time.h for the Time
structure. Soon, Time.h will need to include AbstractOperations.h for
structures defined there. To avoid a circular include, let's put the
ISO types into their own file, so that AO.h does not need to include
any JS type header.
Our BigInt implementation can store the negativity of the division
result in either the quotient or the remainder. This is exposed by an
upcoming prototype, which will reach this division with:
-432000000000000 / 86400000000000000000000
Which has the BigInt division result:
quotient = 0
remainder = -432000000000000
(Our old Temporal implementation also had this bug).
For example, consider the following operation:
const instance = new Temporal.PlainDate(2000, 5, 2);
instance.until("-271821-04-19");
The spec would have us enter a loop to compute the difference between
these dates by incrementing an intermediate date one day at a time.
Instead, we can do some math to skip ahead much closer to the desired
date.
This one is particularly weird as there's a priority order, and we even
have to look at attributes from the container element if we're inside a
subframe.
This is an ad-hoc hack papering over the fact that we can apparently
end up in these places without an active window, and proceeding without
one leads to assertions on WPT.
