Both the from_deps and release_deps transforms were adding the same task
as a dependency but under different keys. We don't actually need
release_deps for anything else here as far as I can tell, so skip it.
Differential Revision: https://phabricator.services.mozilla.com/D187691
This commits integrates the new animation triggered restyle counter into the existing tests to ensure that the counter matches the expected marker count.
Depends on D186714
Differential Revision: https://phabricator.services.mozilla.com/D186715
This is both beneficial for the actual code and an enhancement wrt.
-ftrivial-auto-var-init as it gets rid of a usage of nsAutoCString.
Differential Revision: https://phabricator.services.mozilla.com/D187198
A week ago we got a permafail when requesting to know the location queue for certain data centres for webpagetest
I investigated and found the request was being blocked by cloudflare for some security reasons
Modifying the request URL and modifying headers resolved the issue
Differential Revision: https://phabricator.services.mozilla.com/D187497
Most of this patch is ripping `command-context` out from Gecko. The other parts are the fairly straightforward conversions from `command-context` to `task-context`.
Differential Revision: https://phabricator.services.mozilla.com/D186822
This is only sortof a new issue - it's come up because we longer allow `group_by` functions to be overridden, and the taskgraph version of the `single` group doesn't handle the `only-for` blocks that we use all over the place.
This patch provides a quick fix -- renaming the Gecko `single` group-by to `single-with-filters`, and using that in most places. (There were a couple of places that switching to `with-attributes` was simple enough - but in many cases we cannot yet replicate this functionality with `from-deps` alone AFAIK.)
Differential Revision: https://phabricator.services.mozilla.com/D186821
WorkletThread does not read from preferences to initialize JS::ContextOptions
and relies on the default values it has. This lead to a regression from
bug 1832378 where certain wasm features had their field's default change.
This didn't affect other globals because we read preferences from those
and so the default value is ignored.
This commit fixes the default value for wasm features in JS::ContextOptions
as a temporary fix, and adds a quick test in worklets.
Ideally worklets will read from preferences for consistency and to allow
us to force enable/disable features. But that's a bigger change.
Differential Revision: https://phabricator.services.mozilla.com/D187583
This builds on the light-dark() function added in bug 1845679 to provide
custom colors for both the default light and dark themes, and remove the
"default theme in dark mode" bits.
This is all to be landed after the soft-freeze in any case. Untested on
macOS for now, but no reason it shouldn't work. Will test later today.
On the light theme we were relying on Field / FieldText being black /
white for toolbar-field-focus, so make that explicit too:
InspectorUtils.colorToRGBA("Field", document) // Object { a: 1, b: 255, g: 255, r: 255 }
InspectorUtils.colorToRGBA("FieldText", document) // Object { a: 1, b: 0, g: 0, r: 0 }.
Differential Revision: https://phabricator.services.mozilla.com/D184708
This wasn't really used anymore.
We are fetching the database from the server runtime in order to support
remote debugging correctly, where frontend CSS may be different from debuggee CSS.
Differential Revision: https://phabricator.services.mozilla.com/D187492
This shouldn't change behavior, but it packs the two arguments to
DestroyFrom into a single thing, and makes nsIFrame::Destroy not so easy
to call without a previous context.
This is a prerequisite to pass aDestroyContext to various things that
right now just mint one, which can cause badness, see bug 1851787 and
related bugs.
It's also a bit nicer to add things there if we need to in the future.
Differential Revision: https://phabricator.services.mozilla.com/D187578
