We do that with everything else (i.e. clang, cbindgen, etc.). We weren't
doing it for sysroots because the support was experimental and the path
was independent of the target, so there was no guarantee that the
sysroot would actually work for the target. As that's not the case
anymore, we can go with more consistency with the bootstrapped
toolchains.
Differential Revision: https://phabricator.services.mozilla.com/D120417
ensure_browser_packages is used for another purpose since Bug 1718341.
this also fixed a missing overload for ensure_android_artifact_mode_packages
and ensure_js_packages and some missing arguments in install_android_packages.
Differential Revision: https://phabricator.services.mozilla.com/D120511
TabDescriptor.getTarget now only works if a TargetCommand is setup
and we called startListening on it.
And there is no way to retrieve another tab's target from
a given tab's TargetCommand/commands.
So here we should use two distinct commands.
Note that this test is covering cases we don't really support.
Switching between two distinct tab's top targets isn't something that should happen.
But I think it is still valuable to cover as it may later help us work on bug 1569859.
Differential Revision: https://phabricator.services.mozilla.com/D120358
Because `NativeLayerWayland` uses an invisible 1x1 pixel buffer for
`moz_container_wayland` which only serves as parent surface, not
holding any content.
If we set a buffer scale >1 to it, this would violate the spec:
> The new size of the surface is calculated based on the buffer
> size transformed by the inverse buffer_transform and the inverse
> buffer_scale. This means that at commit time the supplied buffer
> size must be an integer multiple of the buffer_scale. If that's
> not the case, an invalid_size error is sent.
Currently compositors appear to not strictly follow this, only
printing warnings. This could change at any time though.
Differential Revision: https://phabricator.services.mozilla.com/D119995
When the `MozContainer` surface is not yet ready in `Commit()`,
we need to queue the commit.
Similar to `nsWindow` and `WaylandVsyncSource` we can do so by
registering via a callback via `add_initial_draw_callback()`.
This required some logic changes which let to clean ups and
simplifications in the whole file (I'm sorry it got so big).
Differential Revision: https://phabricator.services.mozilla.com/D120429
In future, we want to persist a lot more of the information about
primitive instances between display lists. This will allow us to
implement a number of optimizations and improvements to the scene
and frame building code (such as reducing per-frame per-prim work
that is typically mostly redundant, supporting prims other than
pictures that can contain child primitives, unifying and optimizing
primitive dependency updates).
As a step towards that, this patch introduces a picture graph which
is very similar to the idea of the render task graph builder. With
this in place, we're able to run picture updates without using
recursion, and ensuring we update pictures in the correct order
that the pass requires. This will allow us to un-tangle a lot of
the existing scene building, visibility, prep and batching pass
complexity, in order to be able to implement the above.
Differential Revision: https://phabricator.services.mozilla.com/D120191
This patch introduce an additional check inside the Helper::GetInactiveOriginInfos static method
used internally by CollectOriginsForEviction to ensure that QuotaManager will not select an
extension origin as an inactive origin to evict non persisted data from.
The rationale is that unlike websites (which may more likely using the locally stored data
as a local cache, but still able to retrieve the same data again from the server side),
extensions do not have a remote counterpart and so evicting their data would result
into potential data loss for the users.
Besides that, the browser extensions (unlike websites) are explicitly installed and uninstalled by
the user and all the data associated to the extension will be completely removed when the
extension is uninstalled.
Differential Revision: https://phabricator.services.mozilla.com/D120470
The concept of "events" in the Wasm exception handling proposal
has been renamed to "tags". This commit implements this renaming
in most cases (an exception is text format tests).
Differential Revision: https://phabricator.services.mozilla.com/D118282
The Wasm exception handling spec has changed to rename "events"
to "tags". As a result, `WebAssembly.Exception` gets renamed
to `WebAssembly.Tag` and `WebAssembly.RuntimeException` becomes
`WebAssembly.Exception`.
Differential Revision: https://phabricator.services.mozilla.com/D118281
This is already a known divergence in this test that affects all of WR, rather than a new finding for only Android. We just need to move the fuzz a bit so that Android falls into it as well.
Differential Revision: https://phabricator.services.mozilla.com/D120261
Usually, when an incremental GC is waiting on background tasks to finish we
yield back to the mutator. This patch changes this so that the main thread
blocks until its budget is exhausted in long running GCs where the slice was
triggered by memory allocation. This allows the GC to catch up with the
mutator.
Differential Revision: https://phabricator.services.mozilla.com/D120321
This adds an 'urgent' threshold, which is at a configurable point before we
reach the incremental limit. We calculate how close we are to the limit as a
fraction of bytes remaining until we hit it, giving a value in the range 1 to 0
as we apprach it. Then we increase the slice budget in inverse proportion to
this value, and decreases the allocation threshold for the next slice in
proportion to it.
The value for the urgent threshold is chosen as 16MB since the values for the
incremental limit ratio is chosen so that there is always more than 16MB
between the original GC threshold and the incremental limit. This also allows
the effect to vary from subtle to large over several slices, since alloc
triggered slices are initially 1MB apart.
The calculation is chosen to have no effect at the start (at the urgent
threshold itself), rise slowly but becomes asymptotic as we approach the
incremental limit, with the aim of never reaching this limit.
I couldn't think of a better name than 'urgent threshold'. I think it's
reasonable but it's not very descriptive of how it's used. I'd appreciate any
ideas.
Differential Revision: https://phabricator.services.mozilla.com/D120320
I don't see why this is needed or how we got to this place
but we are getting some divide-by-zero errors and maybe
this will resolve them?
Differential Revision: https://phabricator.services.mozilla.com/D119218
We should only seek to the next keyframe in a really bad situation where the video is way too slow and we probably already drop a lot of frames.
Using the audio clock causes seeking to next key frame is too aggresively. That might happen even if only one video frame is late ,which is usually ignorable and won't cause any effect to users. So we should use the media time to perform such checking, not audio clock time.
Differential Revision: https://phabricator.services.mozilla.com/D120418
This patch draws a 1px black line around the Urlbar in macOS HCM, which resembles other high contrast macOS apps. This patch only supports Light HCM mode. Since we apply the Firefox Dark lwttheme when in Dark mode, and we do not support lightweight themes in high contrast mode, significantly more work is required to implement basic support for dark HCM on Mac.
Differential Revision: https://phabricator.services.mozilla.com/D116406
Jeff Muizelaar
Ryan Hunt
Mike Hommey
Shane Caraveo
Agi Sferro
Butkovits Atila
Alexandre Poirot
Robert Mader
Glenn Watson
Bernard Igiri
Dan Mosedale
Julian Descottes
Luca Greco
Asumu Takikawa
Kajal Sah
Gijs Kruitbosch
Lee Salzman
Andrew Osmond
Andreea Pavel
Jon Coppeard
Francesco Lodolo (:flod)
Tom Ritter
alwu
Iain Ireland
Harry Twyford