Some code in the gradient fast path was expecting that at a certain point we'd either have bailed out of the optimization or the primitive bounds would be tightly clipped. It was possible with a combination of parameters to have a tile repetition that would prevent the tight clipping while being opitmized away after the attempt at clipping. In that case the primitive bounds wouldn't be minimal but we proceed using it as the clip while decomposing gradients into simpler segments.
This patch reorders the optimization code so that clipping is done after sanitizing repetitions, allows the clipping to happen in more cases and as an extra safety uses the intersection of the primitive bounds and clip as the segment clip regardless of whether we achieved a minimal clip earlier.
Differential Revision: https://phabricator.services.mozilla.com/D114255
This test has a fission-specific failure right now, where the failure looks
like a case where the cross-origin resource simply hasn't loaded, or hasn't
loaded *yet*.
This patch adds a short delay (60 "executeSoon" ticks, each of which spin the
event loop). This doesn't make the test take appreciably longer on my machine,
but it does introduce a short delay. If it helps, it'll let us know that
there's simply a race condition which is causing this test's snapshots to be
taken before its iframes' resources are ready.
Differential Revision: https://phabricator.services.mozilla.com/D114285
This should help avoid crashes caused when the content process has
already destroyed a BCG when the parent process hasn't yet. The BCG will
still be destroyed when the content process shuts down using normal
cycle-collection.
Differential Revision: https://phabricator.services.mozilla.com/D113828
I'm changing this to be unconditional so that it may ride the trains.
If we later decide that we need to hold it back for another release, we can
revert this in Beta.
I'm talking to data people about analyzing Fenix's tab retention probes. I'll
obviously be keeping an eye on those numbers as this change propagates.
Differential Revision: https://phabricator.services.mozilla.com/D114404
It seems that we've hit another instance of the XUL box model interacting poorly
with the HTML box model in mysterious ways. In this particular case, the <h2>
elements for subview subheaders was using the HTML box model while inside of
a tree of XUL box elements, and this was causing an incorrect height calculation
for the containing scrollable node, the panel-subview-body.
Switching the h2 element to use the XUL box model appears to fix this.
Differential Revision: https://phabricator.services.mozilla.com/D114384
With Fission, there can be multiple BrowserParents in a single tab, so
this patch moves the tracking of active tabs onto the top BrowsingContext
in a tab. If the priority of a top BC is changed, then the activity
of all of the BPs of the BCs in the tree are all adjusted. The flag
that tracks this state gets carried forward to the new BC in the case
of a cross-group navigation by the changes in ReplacedBy().
The other change here covers the case where we do a process-switching
navigation on an iframe. If we create a new BrowserParent with an active
top BC, then the BP gets marked as active in the priority manager. Doing
this tracking on the BP instead of the BC (both here in and in the part
that landed previously in BrowserParent::Deactivated()) means that we
don't need to track down every place that a BC switches processes.
I left the tracking of activity in ParticularProcessPriorityManager
centered around BrowserParents, instead of changing it to BCs, to
minimize the changes required. There are some tricky interactions there
with wakelocks that I didn't want to have to figure out.
browser_ProcessPriorityManager.js was set up to track a mapping of
browsers to priorities, but for the purposes of testing Fission support
I changed it to track a mapping of child IDs to priorities.
In the test, I also removed an assignment (this.window = null) that
didn't seem to be doing anything.
Differential Revision: https://phabricator.services.mozilla.com/D112213
When the audio sink shutdown, we should also reset the audible state for the listeners. Otherwise, MediaDecoderStateMachine would possibly rely on the incorrect audible state that is produced by previous sink, which would cause showing the sound indicator even if no sound is being playing.
Eg.
Considering following case without the reset of the audible state
1. Sink A is audible -> MDSM set `mIsAudioDataAudible=true`
2. Stop sink
3. Recreate sink B and it's playing silence -> MDSM's `mIsAudioDataAudible=true` is still true, this is wrong!
Differential Revision: https://phabricator.services.mozilla.com/D113550
The purpose of this patch is to create a consistent clock timeline among different media sinks.
Having a consistent clock timeline can help the newly created media sink to understand audio data's "adjusted" time, which can prevent the sink from inserting silence if the sink incorrectly think there is a gap between data and sink start time.
However, once seeking completed, we should use the media time that indicates to the new position, instead of using the previous clock time.
Eg.
Audio duration = 10, and has seamlessly looped 5 times. Then the start time of the sample in 2s in the 6th looping would be 2 + 5*10 = 52.
If we switch to the new sink, and use media time (which is 2s) as a start time to start a new sink, then the new sink would think there is a gap between 2s and 52s and push a lot of silence into the data. [1]
[1] https://searchfox.org/mozilla-central/rev/9b430bb1a11d7152cab2af4574f451ffb906b052/dom/media/mediasink/AudioSink.cpp#390-426
Differential Revision: https://phabricator.services.mozilla.com/D113548
This ends up changing the NoThrow condition on CheckPrivateField to instead emulate the object check of JSOp::In instead.
As well, to create PrivateOpEmitter::Kind::ErgonomicBrandCheck, it's no longer aliased to the ElemOpEmitter::Kind enum.
Differential Revision: https://phabricator.services.mozilla.com/D114024
This ends up changing the NoThrow condition on CheckPrivateField to instead emulate the object check of JSOp::In instead.
As well, to create PrivateOpEmitter::Kind::ErgonomicBrandCheck, it's no longer aliased to the ElemOpEmitter::Kind enum.
Differential Revision: https://phabricator.services.mozilla.com/D114024
PerformanceObserver.supportedEntryTypes doesn't check whether
PerformanceEventTiming is enabled or not, so it'll falsely claims
PerformanceEventTiming is supported even if the pref is disabled.
This patch fixes that by adding a guard to it.
Differential Revision: https://phabricator.services.mozilla.com/D114250
We hook several file APIs to record I/O performance data. Since TLS is not
allocated in ntdll's loader worker thread, however, if someone does a file
operation, we hit read AV because `WinIOAutoObservation` uses `nsString` and
a thread local variable.
Currently we can see this crash happens only when a DLL rule of AppLocker is
defined, but theoretically this can happen when any module loaded in a worker
thread does file operation in its entrypoint.
The proposed fix is to skip `WinIOAutoObservation` if TLS is not available.
Differential Revision: https://phabricator.services.mozilla.com/D113032
For normal seeking operation, we would stop the sink first and restart sink if needed when MDSM enters `DecodingState` later.
We should also do that for seek-to-next-frame. After seeking completes, MDSM would reset the media time by the video keyframe's time, but the audio clock time might still behind because it doesn't skip to next keyframe (audio also doesn't have that concept).
We hit this issue in the `1709130.html` in the previous patch. After seeking completed, the media time (video next keyframe time) is updated but the audio clock time is still behind, so we hit the assertion in the `GetClock()` [1]
[1] https://searchfox.org/mozilla-central/rev/54097530955a98c768f2aaf56925578ec886ec77/dom/media/MediaDecoderStateMachine.cpp#3585
Depends on D114150
Differential Revision: https://phabricator.services.mozilla.com/D114151
