Previously, we only respected the user's system colors preference in the case that a user (a) was not using a high contrast theme or (b) was using the high contrast theme supplied by firefox (FF-HCM).
Any OS-level HCM forced system colors and rendered the checkbox non-functional. We also previously computed visited link color via foreground/background composition, but this is only necessary on Windows HCM where the theme fails to specify a visited link color.
Differential Revision: https://phabricator.services.mozilla.com/D119814
These assertion fails quite frequently with fission and even more with server side targets.
We should investigate that in bug 1722709 before re-enabling this.
Differential Revision: https://phabricator.services.mozilla.com/D121089
The dedicated zone for self-hosting can now be removed entirely. Also remove the
object cloning code that was only used for the old self-hosting mechanism.
Differential Revision: https://phabricator.services.mozilla.com/D120547
The top-level script for selfhosted.js defines a few builtin values when it
executes. Instead of relying on cloning these objects into normal realms, this
patch now executes the script in the target realm itself. We run this script on
demand when we are first looking up a builtin that is neither a C++ intrinsic,
nor a self-hosted function defined in the stencil. In practice, this is not run
except when certain Intl APIs are used in a realm.
Work around the testGCOutOfMemory test now that there is no initial nursery
usage during startup. This test case should be improved in future.
Differential Revision: https://phabricator.services.mozilla.com/D120546
Where we previously queried information directly on the uncloned self-hosted
functions, we now query these flags and names directly from the stencil.
Differential Revision: https://phabricator.services.mozilla.com/D120545
Instead of using script-cloning, delazify by directly instantiating the script
data from the self-hosting CompilationStencil. We are only instantating a single
(top-level) function of the self-hosting at a time, so a special version of the
instantiation code is introduced to handle sub-trees. The CompilationGCOutput is
also giving offset indices to avoid allocations in most cases (since the output
structure reserves inline space).
Differential Revision: https://phabricator.services.mozilla.com/D120544
The previous patch handled the case where a FunctionSpec uses self-hosting, and
this patch now handles self-hosting references to other self-hosted functions.
Previously this was would do a deep-clone, but now we use the lazy self-hosted
function mechanism and delazify on demand.
Differential Revision: https://phabricator.services.mozilla.com/D120543
Instead of using the self-hosted zone as a template to create the initial lazy
self-hosted functions in a Realm, use the stencil data directly. Later patches
will also use this stencil to delazify these functions.
Differential Revision: https://phabricator.services.mozilla.com/D120542
On the JSRuntime, save a mapping from (permanent) JSAtoms to corresponding
self-hosted stencil ScriptIndex. We store both the ScriptIndex and the index of
the next top-level functions. Scripts in this range are sub-scripts of the
target. This is used later to instantiate self-hosted builtins on demand.
Differential Revision: https://phabricator.services.mozilla.com/D120541
In order to instantiate directly from the self-hosting stencil (instead of
cloning from the special zone), we need the stencil to be part of the JS
runtime. This adds 45kB per content process right now, but will allow us to
remove the self-hosting zone entirely which will more than make up for this.
Differential Revision: https://phabricator.services.mozilla.com/D120540
Instead of defining these intrinsics directly on the self-hosting global and
cloning on demand, directly use the JSFunctionSpec in the target global. This
removes the need to pre-define these on the self-hosting global. Use a binary
search to find the intrinsic on first use in a realm and then cache it on the
intrinsics holder object so that the lookup only happens once per realm.
Differential Revision: https://phabricator.services.mozilla.com/D120539
Later patches will run `SetIntrinsic` calls in normal realms instead of relying
on the initial-self-hosting-GC. This means that `GetIntrinsic` can occasionally
see nursery objects so WarpBuilder must be adapted. This is more of an edge case
so simply defer Warp while we wait for a minor GC.
Differential Revision: https://phabricator.services.mozilla.com/D120536
Before this patch the clear tiles were drawn last which meant they would always be drawn on top of all transparent content. It was finde under the assumption that nothing is ever rendered on top of clear tiles, however it turns out to be an issue with the proton window modal darkining which renders some semi-transparent black on top of the whole window (including window controls on windows 8 which use clear tiles). Since the occlusion culling treats clear tiles as opaque they will cut through anything under them regardless of the drawing order, so we can render them before transaprent tiles to get the correct result which is to overwrite what's under the clear tile while still being able to render semi-transparent content on top.
Differential Revision: https://phabricator.services.mozilla.com/D120844
WebExtension reload command is still broken with target switching.
Enabling server targets would break this on all reloads.
So prevent enabling server targets until this is fixed.
Differential Revision: https://phabricator.services.mozilla.com/D120982
This patch adds a `reloadViewport` helper that listen for both the viewport
`load` event and for the next dom-complete DOM event so the page is fully loaded.
This makes the test to pass when server side target switching is enabled.
Depends on D120979
Differential Revision: https://phabricator.services.mozilla.com/D121058
We used to handle navigation with a subtle and complex combination of target-available + dom-loading.
Just because we were missing will-navigate event in some cases.
But will-navigate is now reliable and is fired in all types of navigations.
Differential Revision: https://phabricator.services.mozilla.com/D120961
Accessing TargetMixin.localTab during destroy is risky as it may throw.
Reading TabDescriptor.localTab is safer as it will never throw.
This test was failing intermittently on debug builds.
Differential Revision: https://phabricator.services.mozilla.com/D121055
The old performance panel behaves quite differently in case of target switching.
It will open a brand new profile for the next test, which confuses these tests.
Differential Revision: https://phabricator.services.mozilla.com/D120990
Morgan Reschenberg
Florian Quèze
Cosmin Sabou
Mark Banner
Sandor Molnar
Dave Townsend
Emily McMinn
Thomas Wisniewski
Hubert Boma Manilla
Christoph Kerschbaumer
Gijs Kruitbosch
Andrew Osmond
Alexandre Poirot
Ted Campbell
Kimberly Sereduck
Tooru Fujisawa
Jeff Muizelaar
Nicolas Silva
Harry Twyford
Richard Marti
Nicolas Chevobbe