This test fails already on central if you change this line:
https://searchfox.org/mozilla-central/rev/027893497316897b8f292bde48dbb6da2391a331/image/test/unit/test_private_channel.js#93
by:
Ci.nsIReferrerInfo.EMPTY
Because the previous part of the test populates the image cache. The
test wants to check that the channel for the image load is properly
flagged as private and thus that the http cache is partitioned
appropriately, thus clearing the image caches seems sane.
While at it, also fix it so that we send a valid image instead of base64
text, though that change is not technically needed so feel free to ask
me to remove it.
Differential Revision: https://phabricator.services.mozilla.com/D79848
The compositor / renderer thread puts stuff on the screen by mutating
NativeLayers and then calling NativeLayerRoot::CommitToScreen().
The main thread also calls NativeLayerRoot::CommitToScreen() sometimes.
If we hit the main thread code in the middle of a composition, the NativeLayer
state is inconsistent, so we shouldn't commit it to the screen until the
composition is finished.
Differential Revision: https://phabricator.services.mozilla.com/D79924
This avoids arbitrary precision loss when computing REM units and so on,
which is particularly important if we ever change the base of our app
units (but useful regardless).
Differential Revision: https://phabricator.services.mozilla.com/D79928
This also extracts new private member functions AssignOwned and AssignNonDependent.
Furthermore, it fixes an inconsistency for the dependent case: Formerly,
this caused the substring tuple to be materialized into a linear string
infallibly, although the function was a fallible one. It only assigned the
resulting string fallibly, but this would never have failed, since the
allocation already happened before.
Differential Revision: https://phabricator.services.mozilla.com/D78694
The combination of the following factors causes the test cases to OOM
on 32-bit systems due to a lack of object code space:
* --ion-eager
* very many distinct call sites with one IC cache per call site
* one distinct callee per call site that holds onto a distinct wasm
module
* each wasm module claiming at least one wasm page's worth of code
* IC caches that hold onto the individual functions that are called
Just split the test cases to work around this rare problem.
Differential Revision: https://phabricator.services.mozilla.com/D79988
This helps get sccache hits across source directories.
The previous presentation guaranteed the version of `ftlcdfil.h` in
the tree, while this unorthodox presentation only ensures that the
`freetype2` directory has parent `modules`. This is at least unlikely
to occur in random `/usr/include` directories.
If this turns out to be an issue it would be possible to copy
`ftlcdfil.h` into the object directory, potentially with a unique
name, and then reference that (with a relative path).
Differential Revision: https://phabricator.services.mozilla.com/D73759
Bug 1636207 updated webrtcUI.getActiveStreams to support getting window streams. This updates
the call sites in the legacy webrtc indicator, so we get all streams. In the affected call sites
the streams are used to find and focus the parent window and show the permissions doorhanger.
Differential Revision: https://phabricator.services.mozilla.com/D80030
No idea if that is the real reason why the Browser Toolbox failed opening.
It isn't clear how WorkerTarget detach is implied in toolbox opening?
Differential Revision: https://phabricator.services.mozilla.com/D79159
When loading a sub-script in workers, the corresponding COEP must be set on the channel's nsILoadInfo, such that its CORP header can be checked as expected.
Differential Revision: https://phabricator.services.mozilla.com/D77720
For the modern configuration, the rebuild and non-rebuild cache paths are virtually identical - we now load the app-provided engines, then the user engines. The non-rebuild cache route also applies WebExtensions found by the add-on manager whilst we're starting up, but we can apply that to the rebuild cache route as well.
Differential Revision: https://phabricator.services.mozilla.com/D80056
As long as only int32 values are read, use an int32-only stub. If the Uint32
value doesn't fit in an int32 support loading doubles.
Differential Revision: https://phabricator.services.mozilla.com/D79962
The following simplifications are made:
* Unnecessary function template arguments are removed.
* Unnecessary copy constructor definitions are removed (making the types
movable where possible).
* Iterators are moved where possible rather than copied.
* Unnecessary MOZ_IMPLICIT on a constructor with two arguments is removed.
Differential Revision: https://phabricator.services.mozilla.com/D80015
