This is being added to facilitate moving generation of the update URL to Rust (Bug 1567286). Once that has been completed, we should be able to remove the update URL from its current location in firefox.js so that it is not being duplicated in application.ini.
Differential Revision: https://phabricator.services.mozilla.com/D43300
--HG--
extra : moz-landing-system : lando
For Win32k lockdown, we need to remove the content processes' ability to
call GetICMProfileW(). Since it needs this to retrieve the output color
profile, a new synchronous call is added that allows it to request the
parent process to read this file on its behalf.
The contents of the file are now being cached as well, as this should help
ease some of the increased parent process I/O caused by the children not
being able to do this in their process anymore.
For performance reasons, during launch this information is passed directly
to the child through the SetXPCOMProcessAttributes call
Differential Revision: https://phabricator.services.mozilla.com/D66126
--HG--
extra : moz-landing-system : lando
This avoids a bunch of ugly casts and void pointers, without much overhead
(unlike std::function or such).
Differential Revision: https://phabricator.services.mozilla.com/D68182
--HG--
extra : moz-landing-system : lando
Set the flag on the affected classes, which are:
- CallbackTimeoutHandler
- nsJSArgArray
- CallbackObject
- Console
- MessageEvent
- IDBIndexCursor
- ExtendableMessageEvent
- JSPurpleBuffer
Differential Revision: https://phabricator.services.mozilla.com/D68196
--HG--
extra : moz-landing-system : lando
WorkerThreadPrimaryRunnable possibly indirectly creates a
SendInitBackgroundRunnable (runs on the main thread), which causes a data race
with CompileScriptRunnable (runs on the worker thread) by having an
unsynchronized read/write of WorkerPrivate::mPerformanceCounter.
Differential Revision: https://phabricator.services.mozilla.com/D67434
--HG--
extra : moz-landing-system : lando
The strong reference will be dropped when FutureClientSourceParent is removed,
and we guarantee that all FutureClientSourceParents will either be removed or
replaced with a ClientSourceParent (or at least this is a guarantee that's
supposed to be true).
Depends on D66529
Differential Revision: https://phabricator.services.mozilla.com/D68041
--HG--
extra : moz-landing-system : lando
ClientChannelHelperParent is the thing creating the ClientInfos which aren't
backed by existing ClientSources, so it may make sense for CCHP to tell the
ClientManagerService (CMS) to "expect" or "forget" a "future"
ClientSource(Parent).
When such a ClientInfo is created, CCHP notifies the CMS that a future
ClientSource may be created. This notification has to be observed before any
ClientHandles try to query CMS to a ClientSourceParent, which is the case
because the notification as well as ClientHandleParent constructors occur over
PBackground, and the notification sending method is called first.
CMS is told to forget the future ClientSource whenever a redirect occurs that
would result in the creation of a new ClientSource (i.e. a new ClientInfo). It's
also possible that the ClientInfo's LoadInfo's channel is cancelled. To account
for this, CHCP stores the most recent ClientInfo it's created and tells CMS
to _possibly_ forget the associated future ClientSource in its destructor. It's
possible that the channel completed its load, in which case this notification
is a no-op. This also relies on CHCP being destroyed after the reserved
ClientSource has a chance to both be created and register its
ClientSourceParent.
Differential Revision: https://phabricator.services.mozilla.com/D66529
--HG--
extra : moz-landing-system : lando
The changes only make it possible for ClientManagerService to store
FutureClientSourceParents, but it will not actually store them until
following changesets.
Differential Revision: https://phabricator.services.mozilla.com/D66145
--HG--
extra : moz-landing-system : lando
Also implements SourceTableEntry and nsIDHasher to switch ClientManagerService's
nsDataHashTable to a mozilla::HashMap<nsID, SourceTableEntry> in following
changesets.
Differential Revision: https://phabricator.services.mozilla.com/D66144
--HG--
extra : moz-landing-system : lando
Also update the update-rust.sh script in a couple ways:
- Stop copying the source for mp4parse_fallible into the tree; use crates.io
- Include submodules in mp4parse-rust checkout; needed for tests
- Exclude unnecessary build.rs from mp4parse_fallible, it was causing problems
- Update mp4rust_capi/Cargo.toml patch to exclude cdylib. It's only necessary for test_ffi and causes build problems otherwise
Differential Revision: https://phabricator.services.mozilla.com/D68139
--HG--
extra : moz-landing-system : lando
Focus should remain on the label rather than forwarded to the labeled
element.
Co-Authored-By: Mu-An Chiou <me@muanchiou.com>
Differential Revision: https://phabricator.services.mozilla.com/D67676
--HG--
extra : moz-landing-system : lando
This updates comments to no longer reference the removed CDM 9 interface. Prior
to these changes the comments should have referenced interfaces 9 + 10, but in
some cases the 10 was omitted, so those comments are corrected too.
Depends on D68046
Differential Revision: https://phabricator.services.mozilla.com/D68047
--HG--
extra : moz-landing-system : lando
This patch removes the code that tries to instantiate CDM interface version 9.
This code is no longer needed as Widevine have moved away from this interface.
At the time of writing Chromium have not used this interface for more than a
year, and Mozilla have not shipped CDMs using the interface for at least 6
months.
Differential Revision: https://phabricator.services.mozilla.com/D68046
--HG--
extra : moz-landing-system : lando
After we move the IsOnContentBlockingAllowList to the CookieJarSettings.
We suppose to use this in the Document::RequestStorageAccess() since
this would be called in content processes.
Differential Revision: https://phabricator.services.mozilla.com/D66737
--HG--
extra : moz-landing-system : lando
Right now, we have a ContentBlockingAllowListPrincipal in the
WindowGlobalParent. So, the browse element can directly get this
principal from there. And we can stop sending the
ContentBlockingAllowListPrincipal from the content to parent when
OnLocationChange happens.
Differential Revision: https://phabricator.services.mozilla.com/D66212
--HG--
extra : moz-landing-system : lando
Missing includes, namespace-related issues, and missing template instantiations added to make sources compile without unifying.
Differential Revision: https://phabricator.services.mozilla.com/D68142
--HG--
extra : moz-landing-system : lando
so that references can be released from the main thread and there is no need
to send a message to Console thread.
Depends on D67999
Differential Revision: https://phabricator.services.mozilla.com/D68000
--HG--
extra : moz-landing-system : lando
This provides that ConsoleRunnable no longer has a reference to Console, which
previously needed to be released through a message to the console thread.
Differential Revision: https://phabricator.services.mozilla.com/D67999
--HG--
extra : moz-landing-system : lando
to remove Console instance access from
PopulateConsoleNotificationInTheTargetScope().
Differential Revision: https://phabricator.services.mozilla.com/D67998
--HG--
extra : moz-landing-system : lando
This will support removal of Console class usage from main thread.
Depends on D67993
Differential Revision: https://phabricator.services.mozilla.com/D67994
--HG--
extra : moz-landing-system : lando
Now that ConsoleCallData has nothing to trace, mCallDataStoragePending has no
purpose.
Depends on D67989
Differential Revision: https://phabricator.services.mozilla.com/D67990
--HG--
extra : moz-landing-system : lando
so that all ConsoleCallData members can be destroyed on either thread.
ArgumentData::mArguments hold the same references that
ConsoleCallData::mCopiedArguments held previously. The name change is because
the references are merely stored rather than any deep copy of objects.
Differential Revision: https://phabricator.services.mozilla.com/D67989
--HG--
extra : moz-landing-system : lando
This removes a dependency on JS objects on ConsoleCallData, and a reference to
the arguments on ConsoleProfileWorkerRunnable.
Differential Revision: https://phabricator.services.mozilla.com/D67988
--HG--
extra : moz-landing-system : lando
- Add functionality to clone adopted style sheets for printing.
- Add reftest to ensure that the document's adopted styles show in print.
- Add reftest to ensure that a shadow root's adopted styles show in print.
Differential Revision: https://phabricator.services.mozilla.com/D66517
--HG--
extra : moz-landing-system : lando
We nuke xray waivers when we navigate outer windows out of process,
because it doesn't make much sense to have a waiver in that case.
This patch makes the behavior for navigating to local outer windows
consistent, by also nuking remote window proxies. Hopefully that
won't break anything.
This is Nightly-only for now, because it might break addons.
Differential Revision: https://phabricator.services.mozilla.com/D66495
--HG--
extra : moz-landing-system : lando
This patch initializes the ulIvBits member of CK_GCM_PARAMS, which is new in PKCS11 v3.
For libprio, we instead define NSS_PKCS11_2_0_COMPAT, which yields the old struct definition.
Differential Revision: https://phabricator.services.mozilla.com/D67740
--HG--
extra : moz-landing-system : lando
Converts `security.mixed_content.block_object_subrequest`, `security.mixed_content.block_display_content`, `security.mixed_content.upgrade_display_content`, and `security.mixed_content.block_active_content` to static prefs.
Differential Revision: https://phabricator.services.mozilla.com/D67205
--HG--
extra : moz-landing-system : lando
Converts dom.w3c_pointer_events.implicit_capture to a static pref, removes the initializer in PointerEventHandler.
Differential Revision: https://phabricator.services.mozilla.com/D67204
--HG--
extra : moz-landing-system : lando
Converts `intl.ime.hack.on_ime_unaware_apps.fire_key_events_for_composition` to a static pref.
Differential Revision: https://phabricator.services.mozilla.com/D67203
--HG--
extra : moz-landing-system : lando
Converts dom.datatransfer.mozAtAPIs to a static pref and adds the `do_not_use_directly` field, since the pref is used in combination with an additional check in `DataTransfer::MozAtAPIsEnabled`.
Differential Revision: https://phabricator.services.mozilla.com/D67202
--HG--
extra : moz-landing-system : lando
Converts dom.events.testing.asyncClipboard to a static pref. In its original usage, it called a getter that also added information to the log. This uses the do_not_use_directly field to indicate that the getter should still be used for logging.
Differential Revision: https://phabricator.services.mozilla.com/D67186
--HG--
extra : moz-landing-system : lando
Converts security.data_uri.unique_opaque_origin to a static pref. This pref was initialized by the ClientManager in ClientPrefs, so this commit also removes those files. Somehow this pref was getting added in VarCache twice, so it also removes the places where the pref was added in Networking.
Differential Revision: https://phabricator.services.mozilla.com/D67185
--HG--
extra : moz-landing-system : lando
Converts dom.use_components_shim to a static pref and removes its `all.js` entry.
Differential Revision: https://phabricator.services.mozilla.com/D67184
--HG--
extra : moz-landing-system : lando
Converts dom.vibrator.enabled, dom.vibrator.max_vibrate_ms, and dom.vibrator.max_vibrate_list_len to static prefs. Removes their init function.
Differential Revision: https://phabricator.services.mozilla.com/D67183
--HG--
extra : moz-landing-system : lando
Converts dom.animations.offscreen-throttling to a static pref and removes the static function used to create the varcache pref.
Differential Revision: https://phabricator.services.mozilla.com/D67182
--HG--
extra : moz-landing-system : lando
Moving the trace point for messages to the inner loop allow understanding what
pages are doing better (if they are creating lots of nodes or changing lots of
params, etc.). Also, it is important to be able to characterize `onmessage`
calls.
Having two tracepoints under `ProcessBlockOnPorts` allows gauging the buffer
preparation overhead. vs just the page's processing code.
Differential Revision: https://phabricator.services.mozilla.com/D67464
--HG--
extra : moz-landing-system : lando
We added it so the perf team could run some experiments, and they were done but
the code was left...
Differential Revision: https://phabricator.services.mozilla.com/D67897
--HG--
extra : moz-landing-system : lando
ClientChannelHelperParent is the thing creating the ClientInfos which aren't
backed by existing ClientSources, so it may make sense for CCHP to tell the
ClientManagerService (CMS) to "expect" or "forget" a "future"
ClientSource(Parent).
When such a ClientInfo is created, CCHP notifies the CMS that a future
ClientSource may be created. This notification has to be observed before any
ClientHandles try to query CMS to a ClientSourceParent, which is the case
because the notification as well as ClientHandleParent constructors occur over
PBackground, and the notification sending method is called first.
CMS is told to forget the future ClientSource whenever a redirect occurs that
would result in the creation of a new ClientSource (i.e. a new ClientInfo). It's
also possible that the ClientInfo's LoadInfo's channel is cancelled. To account
for this, CHCP stores the most recent ClientInfo it's created and tells CMS
to _possibly_ forget the associated future ClientSource in its destructor. It's
possible that the channel completed its load, in which case this notification
is a no-op. This also relies on CHCP being destroyed after the reserved
ClientSource has a chance to both be created and register its
ClientSourceParent.
Differential Revision: https://phabricator.services.mozilla.com/D66529
--HG--
extra : moz-landing-system : lando
The changes only make it possible for ClientManagerService to store
FutureClientSourceParents, but it will not actually store them until
following changesets.
Differential Revision: https://phabricator.services.mozilla.com/D66145
--HG--
extra : moz-landing-system : lando
Also implements SourceTableEntry and nsIDHasher to switch ClientManagerService's
nsDataHashTable to a mozilla::HashMap<nsID, SourceTableEntry> in following
changesets.
Differential Revision: https://phabricator.services.mozilla.com/D66144
--HG--
extra : moz-landing-system : lando
Since we cannot use HTMLInputElement.GetInputMode since we still support
mozAwesomebar, inputmode attribute isn't sanitized. Since I would like to reduce
comparing cost, it should be lower case except to mozAwesomebar.
Differential Revision: https://phabricator.services.mozilla.com/D67770
--HG--
extra : moz-landing-system : lando
The top-level document containing the iframe in which the test runs can be
scrolled by things that happen in previous tests (e.g. a zoomToFocusedInput
in a previous test), causing the target element to be outside of the visual
viewport.
After bug 1556556, event synthesization functions will no longer support
targeting elements outside the visual viewport.
Differential Revision: https://phabricator.services.mozilla.com/D67523
--HG--
extra : moz-landing-system : lando
The tests don't have a reliable mechanism to wait for a potential zoom
animation to end, leading to flakiness due to a zoom animation form a previous
sub-case interfering with the current sub-case.
Differential Revision: https://phabricator.services.mozilla.com/D67522
--HG--
extra : moz-landing-system : lando
The coordinate values are chosen to target the first pixel of a target frame.
However, due to rounding error during the event synthesization code path,
they can miss the frame by a fraction of a pixel.
Differential Revision: https://phabricator.services.mozilla.com/D67520
--HG--
extra : moz-landing-system : lando
Previously, we kept the object IDs managed on content side only.
The GPU side would work with given indices.
When an object is destroyed, we'd free the ID on the content side and signal the GPU to delete the object.
Problem is that on the GPU process the object may still be kept alive for as long as any dependants are alive.
What this change is doing - hooking up the callbacks to the *actual* freeing of IDs on the GPU side.
These callbacks end up in messages from WebGPUParent to WebGPUChild, and only then the IDs are freed
on the content side and able to be reused.
Differential Revision: https://phabricator.services.mozilla.com/D67211
--HG--
extra : moz-landing-system : lando
This commit includes all the manual changes needed to get 'wasm/' jit-tests
passing.
Differential Revision: https://phabricator.services.mozilla.com/D67255
--HG--
extra : moz-landing-system : lando
Xray waivers for remote window proxies don't make much sense, so we nuke any
waiver when a window proxy navigates from local to remote. However, this xray
waiver can be the target of a CCW, and dead wrappers are not supposed to the
target of a CCW, so we need to find and nuke any CCWs targetting the waiver.
This requires fixing js::RemapWrapper so that it can be used to fix CCWs to
dead wrappers.
Hopefully this will fix a bunch of intermittent failures in
browser_windowProxy_transplant.js.
Differential Revision: https://phabricator.services.mozilla.com/D66459
--HG--
extra : moz-landing-system : lando
After bug 1582832, DocShell destruction and BrowsingContext detaching happen
in separate operations, leaving a gap where a DocShell has been destroyed, but
its BrowsingContext is still considered attached. During this gap, the usual
invariant that an in-process, attached BrowsingContext always has an
associated DOM window doesn't hold, nor do the usual invariants for outer
window forwarding security checks.
This patch fixes the detach timing so that a child BrowsingContext for a frame
which has been removed is always marked detached at the same time its DocShell
is destroyed.
Co-authored-by: Kris Maglione <maglione.k@gmail.com>
Differential Revision: https://phabricator.services.mozilla.com/D62791
--HG--
extra : moz-landing-system : lando