Moves InitExpr declarations from WasmTypes.h
to WasmInitExpr.h. The definitions already lived in
their own translation unit, so this is a header
only change.
Differential Revision: https://phabricator.services.mozilla.com/D117043
For "c" (i.e., gcc, clang, and clang-cl), this configures the
`-f{debug,macro}-path-prefix` flags. We'd prefer to use
`-ffile-path-prefix`, but it seems that `clang-cl` does not recognize
that flag.
For "rust" (i.e., rustc/cargo), this configures `--remap-path-prefix`.
This is one step toward getting `sccache` hits across source and
object directories.
Differential Revision: https://phabricator.services.mozilla.com/D113065
I renamed the pref to resultGroups. This is similar enough that we don't have to change a lot of code. Functions and comments that refer to resultBuckets now clearly refer to resultGroups. As Marco pointed out in the bug, the renaming is necessary to avoid conflicts with old versions.
Differential Revision: https://phabricator.services.mozilla.com/D117354
I haven't been able to reproduce the issue here locally and test this directly, but according to
the reporter a build with this patch works for them.
My guess is that perhaps IDWriteLocalizedStrings::GetLocaleName has been returning a failure result,
causing us to drop the relevant font from the list altogether. We can handle that better by still
including the font, even if we're unsure which name matches the system locale.
This patch also adds a few gfxWarning() messages in places where we really don't expect things
to fail, but if they do, it might help us understand why fonts fail to appear.
Differential Revision: https://phabricator.services.mozilla.com/D117406
This allows any external tasks that happen to run after the helper thread
system has shut down to correctly detect that. This shouldn't happen with the
next patch but it seems safer to do it this way.
Differential Revision: https://phabricator.services.mozilla.com/D117004
Tasks are dispatched by queueing a generic task for the pool. When this is
executed it will run the highest priority task pending, if any.
In a busy system it's possible that there will be some delay between
dispatching this task and it starting running. There is also a limit on the
number of tasks that are run at once for each task kind. The patch therefore
limits the number of tasks dispatched to the number of avilable threads.
Differential Revision: https://phabricator.services.mozilla.com/D116817
This is a stronger condition because we assert CanUseExtraThreads during
initialization. It's also closer to to the original intent.
Differential Revision: https://phabricator.services.mozilla.com/D116814
The previous patch added a pref to control use of the external thread pool. I
don't think we need an environment variable as well, although I could be
persuaded to keep this.
Differential Revision: https://phabricator.services.mozilla.com/D116813
In order to avoid system compositor and wire overhead.
Also make more internals of `NativeSurfaceWayland` private.
Depends on D116675
Differential Revision: https://phabricator.services.mozilla.com/D116721
Make the vsync source request frame callbacks from opaque native
layers. This is necessary as opaque layers may occlude the
MozContainer surface, which is normally used for frame callbacks.
Wayland compositors may (and are encouraged to) optimize away
such callbacks, so we need to make sure to request frame callbacks
from actually visible surfaces.
Callbacks are requested for all layers, but only the first callback
will trigger the vsync source.
In order to get this right concerning multiple requested callbacks,
possibly being called from different threads etc., introduce a
callback abstraction, `CallbackMultiplexHelper`, to make this simple
to handle for callers.
Differential Revision: https://phabricator.services.mozilla.com/D116026
This is important to emit `connectFromContent` before processing the watched data.
We have to notify the parent process (and the client) about the new target actor.
And do that before any code in the content process tries to emit an event via this target acotr.
We will typically start the resources watchers when processing the watched data,
which will emit the resources-available-form on the target actor.
Writing a test for this is a bit tricky, as we start missing event when we get into it.
browser_resources_document_events.js starts failing without this patch because DOCUMENT_EVENT's dom-loading is emitted immediately
and is lost in the parent process.
I'm not sure we can write a better test than this existing failure.
Differential Revision: https://phabricator.services.mozilla.com/D117149
These events are redundant with target creation and destruction when the targets
follows the window lifecycle. These events are now only useful for in-process iframes.
Also, when the Target is instantiated by the server codebase, we end up registering
the code emitting these events sooner, so that we emit window-ready for the existing document!
On top of that, we end up also instantiating (and attaching) the thread actor earlier.
When combined, the thread actor was receiving window-ready for the existing top document
and was reseting itself after being attached and having registered the breakpoints.
Some followup would be required for will-navigate.
We get an initial will-navigate when the target instantiate, which can also confuse actors.
But as this event is important for DocumentEventWatcher, more work is needed to disable it.
Differential Revision: https://phabricator.services.mozilla.com/D117148
I thought I would reused browser_dbg-navigation.js, but its doc-scripts.html
test page is too complex and doesn't reproduce the broken breakpoint.
So I'm still cleaning it up, but ended up introducing a new dedicated test and test page.
Note that I'm removing the toggleScopes call as it was most likely a workaround.
Test helpers assume that scopes are visible and timeout if the scopes don't get updated.
The added test now only fails without fission + with server target switching.
Differential Revision: https://phabricator.services.mozilla.com/D116811
This does a few things:
1. Removes the `aImmediately` flag from the RequestSHistoryUpdate path, and
moves that responsibility to SessionStore
1. Simplifies how and when SessionStore calls SessionHistory.collectFromParent()
1. Attempts to clean-up SessionStore's SHistoryListener (again)
Differential Revision: https://phabricator.services.mozilla.com/D117230
While webrender has been shipping for a long time on other Adreno 5xx
devices, we had disabled it on Adreno 505 and 506 due to frequent
crashes during shader compilation. This crash has now been fixed, so
we can ship webrender to these devices.
Depends on D117427
Differential Revision: https://phabricator.services.mozilla.com/D117428
On certain adreno devices we encountered frequent driver crashes
during glLinkProgram. The crash appears to be caused by a combination
of compiling a shader with some GLSL code the driver doesn't like,
compiling shaders concurrently in multiple threads (eg webrender's
renderer thread and Fenix's Android UI render thread), and said
threads having a certain stack address.
Specifically, the GLSL code the driver doesn't like is a vector
bitwise-and followed by a conversion to bvec, which occurs in many of
webrender's shaders.
While we have control over webrender's renderer thread, we are unable
to synchronize with or control the stack address of the UI render
thread. Fortunately, we can rewrite the GLSL code to use scalar
bitwise-ands, therefore avoiding the crash.
Differential Revision: https://phabricator.services.mozilla.com/D117427
The values for spoofVendorID/spoofDeviceID should match entries in
test_gfxBlacklist_AllOS.json. These entries were added in
https://hg.mozilla.org/mozilla-central/rev/21263fbfdcc2 but
inadvertently not updated (because the test was disabled).
Fixing that enables the test to use the expected entries.
Several test expectations were no longer correct for Android and have
been updated as well.
Differential Revision: https://phabricator.services.mozilla.com/D116953
test_gfxBlacklist_Equal_DriverNew.js fails on Android because the
meaning of "All" was changed by bug 1274635 to mean "All Windows"
instead of "All OSs", while the test relied on mock data in
test_gfxBlacklist.json that contains entries for "os": "All".
To fix the failures, add entries to test_gfxBlacklist.json based on
these existing `"os": "All"` entries, with driver version ranges chosen
to as closely match the original entry (greater/lower/equal compared to
6 (from `gfxInfo.spoofDriverVersion("6")`) in the test file).
Differential Revision: https://phabricator.services.mozilla.com/D116952
Just emit `dmb ish` for every barrier, do not try to use more
discriminating barriers such as `dmb ishst` as they are hard to reason
about.
Differential Revision: https://phabricator.services.mozilla.com/D117282
Ryan Hunt
Nick Alexander
Harry Twyford
Jonathan Kew
Andrey Bienkowski
Christoph Kerschbaumer
Jon Coppeard
Robert Mader
Alexandre Poirot
ffxbld
Julien Cristau
Kashav Madan
Alexandru Michis
Jamie Nicol
Marco Bonardo
Rob Wu
cerkiewny
Lars T Hansen
Tooru Fujisawa
Nicolas Silva