The principals used in worklet scripts derive from the relevant settings object
of the main thread Worklet object, rather than the network loads of the scripts.
Moving the data off LoadInfo removes any implication that the principals might
depend on script module loads.
Differential Revision: https://phabricator.services.mozilla.com/D44775
--HG--
extra : moz-landing-system : lando
We can end up in here from a style worker thread. But that's safe since
we only read data from the FontFaceSet, and the main thread is blocked
so writes can't happen underneath us.
Differential Revision: https://phabricator.services.mozilla.com/D44589
--HG--
extra : moz-landing-system : lando
The `padding-right` is the only oversight afaict. This patch is based on D45125.
Differential Revision: https://phabricator.services.mozilla.com/D45126
--HG--
extra : moz-landing-system : lando
When toolbar is wrapped onto two rows, the second row to have white background, class `devtools-input-toolbar` is being added up
onto `devtools-toolbar devtools-input-toolbar`
Differential Revision: https://phabricator.services.mozilla.com/D42665
--HG--
extra : moz-landing-system : lando
`WindowsErrorResult` is a class to hold either a value or a Windows error
code based on the `Result` template. We also have `LauncherResult` for the
same purpose, which was introduced as a part of the launcher process feature
afterward. The difference is `LauncherResult` holds a filename and line
number along with an error code.
This patch integrates LauncherResult.h into WinHeaderOnlyUtils.h so that we
can use `LauncherResult` more broadly.
Differential Revision: https://phabricator.services.mozilla.com/D44512
--HG--
extra : moz-landing-system : lando
The test originally assumed that the BrowsingContext for the crashing
frame would get destroyed and replaced with a new one. Having read through
some of bug 1563619 though, it looks as if we preserve the BrowsingContext
after the subframe crashes, so I've modified the test to skip that check.
It also looks like we have to wait until the WindowGlobalParent is created
asynchronously from the about:blank load that's initiated in the content
process before we can query the subframe for its current location, so
I've added a waitForCondition for that.
Differential Revision: https://phabricator.services.mozilla.com/D43814
--HG--
extra : moz-landing-system : lando
Specially permit www.mozilla.org after ensuring other origin checks but failing ALLOW_ACTION.
Differential Revision: https://phabricator.services.mozilla.com/D45069
--HG--
extra : moz-landing-system : lando
PresentScreenBuffer() or screen->PublishFrame() may fail for different reasons. In that case we shouldn't call surface->Commit() because it may be in a not swaped state or not available.
Differential Revision: https://phabricator.services.mozilla.com/D44813
--HG--
extra : moz-landing-system : lando
Previously we were only doing this if content wasn't prevent-defaulting the
events targeting the new APZC.
Differential Revision: https://phabricator.services.mozilla.com/D44712
--HG--
extra : moz-landing-system : lando
This define is unused, modulo some apparently dead patches in the
gfx/skia/patches/archive/ directory.
Differential Revision: https://phabricator.services.mozilla.com/D45086
--HG--
extra : moz-landing-system : lando
This fixes a bug that was introduced three years ago in bug 1268854.
What happened was that the final pass over the polygon assumed that the current
polygon was living in plane[0]. But due to the double buffering, the "current"
polygon alternates between plane[0] and plane[1]. And bug 1268854 had introduced
an early exit so that we could hit the final pass at a time where the current,
now empty, polygon was in plane[1]. So we would incorrectly treat all 32 points
in plane[0] as part of the final polygon.
This bug was responsible for intermittently unreasonable numbers in CompositorOGL's fill
rate / overdraw overlay, and, since changeset cc84a0e9d5ddde198422f4f11ab6bf85f631d5f0,
also caused CompositorOGL to execute unnecessary draw calls.
Differential Revision: https://phabricator.services.mozilla.com/D44312
--HG--
extra : moz-landing-system : lando
One of the things bug 1567616 did was to change how .cargo/config is
preprocessed, from it happening during configure to it happening during
the build. And to make things happen properly, dependencies were added
on the rust targets to ensure the .cargo/config file is created before
they run.
Unfortunately, that changed the order in which Make would run all the
targets while recursing for the compile tier, when the file doesn't
exist first. So instead of starting the compile tier with rust targets,
it would start with most C++, then do rust... which we know to make
builds slower overall because of the need to wait for those rust builds
to finish which C++ has all been dealt with already, and lacking
parallelism during the rust build.
So we force .cargo/config to be generated during export (which it is not
already because OBJDIR_PP_FILES are currently dealt with during misc).
That makes Make still run the rust targets early during the compile
tier.
And while here, we extend the if block in recurse.mk that excludes all
the top-level recursion dependencies when running from subdirectories.
Differential Revision: https://phabricator.services.mozilla.com/D44992
--HG--
extra : moz-landing-system : lando
