When creating workers, dedicated workers, shared workers, we will set
the storage prinicpal to the worker load info. During getting the storage
principal, we need to check the storage permission in the content process.
However, we don't have the hasStroagePermission flag which is needed to do
the check since the channel that we use to get the principal is not opened
yet at the moment.
To address this issue, we can copy the hasStoragePermission flag from
the doucment of the window which creates the worker. Because the worker
would be the same-origin as the window. So, the hasStoragePermission
flag is supposed to be the same between the window and the worker.
We don't need to do anything for the service worker since the storage
permission won't be checked due to the service worker is disabled for
third party trackers. And the storage permission is for the third party
trackers. Thus, we can ignore this flag for service workers.
Differential Revision: https://phabricator.services.mozilla.com/D69810
--HG--
extra : moz-landing-system : lando
Bug 1620197 accidentally moved the parentheses for 'max' outside of the
multiplication by sizeof(Value).
Differential Revision: https://phabricator.services.mozilla.com/D70126
--HG--
extra : moz-landing-system : lando
In particular, this correctly treats as invalid patterns like "a)(b" that only "become" valid due to the addition of the (?:) non-capturing group, that's originally used to allow the addition of ^ and $ anchors.
Differential Revision: https://phabricator.services.mozilla.com/D70143
--HG--
extra : moz-landing-system : lando
When I first added this method last year, I added it in JS, handled from within
SessionStore.jsm, as that was the easiest place to do it. Now that
DocumentLoadListener exists, it makes more sense to handle this logic directly
from within that code.
Many parts of the process switch are still handled by frontend JS, such as
selecting remote types, and performing toplevel process switches.
Differential Revision: https://phabricator.services.mozilla.com/D68594
--HG--
extra : moz-landing-system : lando
We lifted this restriction because with bug 656036 it makes sense to zoom into a
focused input in a fixed subtree. But this causes undesired panning up.
We could conceivably fix it if needed, but for now preserve the previous
behavior of not panning nor zooming.
Differential Revision: https://phabricator.services.mozilla.com/D69946
--HG--
extra : moz-landing-system : lando
The instantiations of the externed templates need to be in the same translation unit as the definitions. Currently they work due to building in unified mode.
Differential Revision: https://phabricator.services.mozilla.com/D69467
--HG--
extra : moz-landing-system : lando
Emptiness of values should be checked using the `empty` method, and not
by comparing the size to 0. Fix such case in the code of
ClearKeyDecryptionManager.cpp module.
Differential Revision: https://phabricator.services.mozilla.com/D70206
--HG--
extra : moz-landing-system : lando
Update code in a few places to work with Python 3, especially with regard to how we invoke subprocesses with text output. Note that the Marionette test harness code needs to be updated so that text is written out in the correct encoding (see bug 1615748).
Differential Revision: https://phabricator.services.mozilla.com/D69012
--HG--
extra : moz-landing-system : lando
MatchOnly mode is a hack. Instead of rewriting it for our new irregexp import, I'm just removing it.
Differential Revision: https://phabricator.services.mozilla.com/D69629
--HG--
extra : moz-landing-system : lando
This patch introduces a new DLL blocklist type `RedirectToNoOpEntryPoint`
which hooks a DLL's entrypoint into a no-op function. With this technique,
we give the injected DLL no chance to run its code though we allow it to be
loaded into the process.
This new blocklist type is intended to block a DLL which is injected by IAT
patching which was planted by a kernel callback routine for LoadImage. It's
because blocking such a DLL makes a new process fail to launch.
Differential Revision: https://phabricator.services.mozilla.com/D68348
--HG--
extra : moz-landing-system : lando
This patch introduces `Kernel32ExportsSolver` which calculates RVAs of
kernel32's functions and transfers them to a target process, where the
transferred RVAs are resolved into function addresses.
Depends on D68346
Differential Revision: https://phabricator.services.mozilla.com/D68347
--HG--
extra : moz-landing-system : lando
This patch introduces a new DLL interceptor `WindowsDllEntryPointInterceptor`
which applies a hook to a target function without backing up the original
function code.
Depends on D68345
Differential Revision: https://phabricator.services.mozilla.com/D68346
--HG--
extra : moz-landing-system : lando
This patch introduces a new policy `MMPolicyInProcessEarlyStage` which does
not consume any functions imported from kernel32.dll so that we can use it
in a process's early stage i.e. before IAT is resolved.
Depends on D68344
Differential Revision: https://phabricator.services.mozilla.com/D68345
--HG--
extra : moz-landing-system : lando
`WindowsDllDetourPatcher::CreateTrampoline` does not only create a trampoline
region but also applies a patch on an original function. This patch extracts
the patching part as separate functions.
Differential Revision: https://phabricator.services.mozilla.com/D68344
--HG--
extra : moz-landing-system : lando
This patch moves the instantiation of `PEHeaders` from `CheckBlockInfo` to
`IsDllAllowed` so that `IsDllAllowed` can use an instance of `PEHeaders`.
Depends on D68342
Differential Revision: https://phabricator.services.mozilla.com/D68343
--HG--
extra : moz-landing-system : lando
This patch introduces `nt::VirtualQuery` which consumes only ntdll's functions
to reduce dependency in `MMPolicy` on kernel32.dll. With this, `MMPolicy` still
depends on kernel32.dll, that will be solved by a coming patch.
Differential Revision: https://phabricator.services.mozilla.com/D68342
--HG--
extra : moz-landing-system : lando
Also: os._exit is much faster than sys.exit, so remember to flush stderr or
we won't see the errors we just printed.
Differential Revision: https://phabricator.services.mozilla.com/D70047
--HG--
extra : moz-landing-system : lando
Entries in the xpcshell.ini manifest override the default specified on the command line.
Differential Revision: https://phabricator.services.mozilla.com/D70166
--HG--
extra : moz-landing-system : lando
Disables FTP protocol handler on nightly. FTP scheme is handled by external protocol handler if it isn't explicitly disabled with preference network.protocol-handler.external.ftp = false.
Differential Revision: https://phabricator.services.mozilla.com/D68974
--HG--
extra : moz-landing-system : lando
This adds the ability to do four-stage PGO builds. This was surprisingly straightforward thanks to PGO being a well-supported scenario in LLVM's cmake.
For reference, the stages are:
stage1: Initial build with gcc
stage2: Instrumented build using stage1
stage3: Train by using the instrumented stage2 to build the clang tree
stage4: Optimize using the stage3 compiler and the profdata created with it
Differential Revision: https://phabricator.services.mozilla.com/D69080
--HG--
extra : moz-landing-system : lando
Separating out the mechanical/"boring" changes to make the next patch more clear. This patch adds the ability to build a fourth stage that for now doesn't do anything special.
I changed to using >= to make it more obvious that e.g. "here is what's going to happen for stage 2" -- the off-by-one was too hard on my brain.
Differential Revision: https://phabricator.services.mozilla.com/D69079
--HG--
extra : moz-landing-system : lando
Otherwise, PGO builds would fail to find asan at stage2 because the instrumented build uses `LLVM_BUILD_RUNTIME=No`.
Differential Revision: https://phabricator.services.mozilla.com/D69082
--HG--
extra : moz-landing-system : lando
This will partially atone for making builds longer with PGO.
Depends on D69618
Differential Revision: https://phabricator.services.mozilla.com/D69620
--HG--
extra : moz-landing-system : lando