When redirects are involved, `DocumentLoadListener::DoOnStartRequest`
may call `ReplaceLoadingSessionHistoryEntryForLoad`, which updates the
history entry with the destination of a redirect. But if the redirection
target is a `moz-extension:`-URL, the URL becomes a jar:file:/file: URL.
This is because SessionHistoryInfo (in SessionHistoryEntry.cpp) looks up
the URL with `nsIChannel::GetURI`. For `moz-extension:`-URLs, the
underlying channel has a `jar:file:` or `file:` URL, as provided by
ExtensionProtocolHandler (via SubstitutingProtocolHandler::NewChannel).
For details, see https://bugzilla.mozilla.org/show_bug.cgi?id=1826867#c7
To fix this, this patch switches to `NS_GetFinalChannelURI` instead. For
more history on this type of bug and SessionHistoryInfo, see
https://bugzilla.mozilla.org/show_bug.cgi?id=1826867#c9
Original Revision: https://phabricator.services.mozilla.com/D234333
Differential Revision: https://phabricator.services.mozilla.com/D236901
emulator.py currently has an unconditional telnetlib import, but the
file can also be imported when the functionality is not needed.
Because telnetlib was removed from Python 3.13, this unconditional
import breaks use cases that do not even care about telnet. As a stopgap
measure until a better fix is available, move the import to the function
that relies on telnet.
Original Revision: https://phabricator.services.mozilla.com/D227995
Differential Revision: https://phabricator.services.mozilla.com/D236164
We can resolve them off the main thread now due to registered custom
properties (which requires the computed <url> serialization).
Differential Revision: https://phabricator.services.mozilla.com/D234959
Without the early exit, DecryptCbcs() will try to get the address of the first
element in the subsample (Span), which with length 0 is forbidden.
This could also be solved by getting the address of the Span through data()
instead, to avoid dereferencing the first element. That seems more like a
footgun than the early exit however.
Original Revision: https://phabricator.services.mozilla.com/D235310
Differential Revision: https://phabricator.services.mozilla.com/D235407
Truncating them generally makes sense, but may be unexpected by some
websites, and rounding consistently with other APIs like client* is
probably more important than showing useless scrollbars in some cases.
I checked Chromium and it seems they round both client* / scroll* /
offset* APIs, and inner{Width,Height} (though they seem to round exact
half pixels down instead of up), so this should probably be safe.
This is tested already by
testing/web-platform/mozilla/tests/css/cssom/window_size_rounding.html
Differential Revision: https://phabricator.services.mozilla.com/D228960
See the testcase. If we replace a transition and flush it in the
meantime, after a timeout, we may fail to set a proper `mPendingReadyTime`
for the newly-created transition, because the refresh driver is not in
refresh when we call `Animation::EnsurePaintIsScheduled()` in
`Animation::PlayNoUpdate()`. So we don't have a pending ready time and
so we cannot trigger this transition at the current tick.
Therefore, this newly-created transition would be triggered at the next tick.
The means it doesn't have `mStartTime` when we enqueued the transition event
i.e. transitionrun, at the current tick. `zeroTimeStamp` would be null,
and we fail to sort the events.
In this patch, we just assign a proper schedule time for transitionrun
if `zeroTimeStamp` is null.
Original Revision: https://phabricator.services.mozilla.com/D226213
Differential Revision: https://phabricator.services.mozilla.com/D235387
Since the cancelled transition has no owning element and its transition
generation is out-of-date, so we have to compare the event targets and
the transition generations in `AnimationEventInfo`. We still follow the
composite order defined in the spec but use the event target and transition
generation before cancelling this transition, to get the correct event order
if we have the same schedule time.
Original Revision: https://phabricator.services.mozilla.com/D225117
Differential Revision: https://phabricator.services.mozilla.com/D235386
We need this information when comparing the cancelled transitions/animations
in the following patches.
Note that we have to reorder the calling of `Animation::Cancel()` and
the update of `mAnimationIndex` to make sure we enqueue the cancel event
with the correct `mAnimationIndex`.
Original Revision: https://phabricator.services.mozilla.com/D227110
Differential Revision: https://phabricator.services.mozilla.com/D235385
