When I initially implemented it for GTK, I just followed the Highlight color
everywhere, but on macOS it makes of course a lot of sense to use
NSColor.controlAccentColor.
Differential Revision: https://phabricator.services.mozilla.com/D114430
So that margin is not included in the rect for visibility calculations,
and padding and margin are accounted properly on them.
Differential Revision: https://phabricator.services.mozilla.com/D113853
Previously we called GetFrontBufferSize, alloc'd a buffer, and called
FrontBufferSnapshotInto to read into the buffer.
Now, call FrontBufferSnapshotInto({}) to get size, and then alloc and
pass pointer to newly alloc'd data into
FrontBufferSnapshotInto(Some(ptr)).
Using the same function for both means that logic can't diverge and
cause mismatch bugs.
Differential Revision: https://phabricator.services.mozilla.com/D113611
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
Daisuke Akatsuka
Kagami Sascha Rosylight
Noemi Erli
Sean Feng
Paul Bone
Emilio Cobos Álvarez
Jeff Gilbert
Csoregi Natalia
Botond Ballo
Karl Tomlinson
Barret Rennie
Nicolas Silva
Dão Gottwald
Daniel Holbert
Mike Hommey
Nika Layzell
Aaron Klotz
Morgan Reschenberg
Mike Conley
Andrew McCreight
alwu
Matthew Gaudet
Joel Maher
Henrik Skupin