Previously the process startup timestamp was computed lazily but this caused
some issues with some of our static analysis infra (see bug 1678152). This
moves computing the timestamp early during process startup and makes it happen
unconditionally.
Differential Revision: https://phabricator.services.mozilla.com/D136406
This seems like it will be useful to help figure out what is being
created/destroyed at inappropriate times, and identify potential
problems faster.
Differential Revision: https://phabricator.services.mozilla.com/D136944
Previously the process startup timestamp was computed lazily but this caused
some issues with some of our static analysis infra (see bug 1678152). This
moves computing the timestamp early during process startup and makes it happen
unconditionally.
Differential Revision: https://phabricator.services.mozilla.com/D136406
Adds a crash annotation, `LinuxUnderMemoryPressure`, which the memory pressure monitor updates based on whether or not it is under memory pressure.
Differential Revision: https://phabricator.services.mozilla.com/D133555
If the theme is dark but user prefers light pages, the background of the
tabpanel should arguably be light, since it can be seen across some
navigations.
Expose a -moz-content-prefers-color-scheme media query to chrome pages
so that our UI can correctly query it (and remove the unused -moz-proton
atom while at it).
Differential Revision: https://phabricator.services.mozilla.com/D136437
The behaviour which this test was intended to test was only used in
release builds, due to the diagnostic assertion in other builds. The new
equivalent of this assertion has been upgraded to a release assertion,
so the test should no longer be required.
Differential Revision: https://phabricator.services.mozilla.com/D136297
ASan builds use more stack space so need a larger stack size. Note that this matches
what we already do for the JS overrecursion limit for the main thread.
This fixes overrecursion errors from the parser when parsing JS files off-thread
on YouTube.
Differential Revision: https://phabricator.services.mozilla.com/D135201
The pseudo-class and nsContextMenu context attribute were using reveal,
the pseudo-element and webidl attribute were using "show".
Use reveal consistently and update the accesskey so that there aren't
conflicts with existing commands. Also enable the feature in
browser_contextmenu_input.js so that this change is tested.
Differential Revision: https://phabricator.services.mozilla.com/D136086
Allows AVX SIMD instructions on x86/x64. Mostly as experiment for benchmarking --
if success, it will be on if available.
Differential Revision: https://phabricator.services.mozilla.com/D135561
The edit-related commands are special because they are handled by ShortcutKeyDefinitions.cpp yet we have duplicate keys because we want the menu disabled state to update properly, so we don't fire command events on those.
Differential Revision: https://phabricator.services.mozilla.com/D135157
The edit-related commands are special because they are handled by ShortcutKeyDefinitions.cpp yet we have duplicate keys because we want the menu disabled state to update properly, so we don't fire command events on those.
Differential Revision: https://phabricator.services.mozilla.com/D135157
Previously all xpidl constants were specified as `i64` which means they require
casts before being passed to any xpcom methods. The lack of typing was not an
issue in c++ due to implicit casts from enums to integer types, but using the
correct type is much more valuable in Rust.
Differential Revision: https://phabricator.services.mozilla.com/D135165
The constants must fit within an int32_t or uint32_t as that is required by the
JS backend with xpt types holding a `uint32_t` and signed bit.
Differential Revision: https://phabricator.services.mozilla.com/D135164
This change aims to make the way that the nsStringInputStream owns the backing
data buffer more flexible. This has a few impacts, including allowing
arbitrarily large payload sizes on 64-bit platforms, not requiring as complex
checks around borrowed string buffers or nsTArray data storage, and supporting
custom data ownership schemes such as those used by blobs.
The new system uses a separate refcounted object internally to provide the
contiguous backing buffer, with the nsStringInputStream wrapping it and
providing the `nsIInputStream` interface and cursor. This also avoids issues
around the buffer being mutated during reads, as mutating the `nsIInputStream`
no longer mutates the actual data storage object.
Differential Revision: https://phabricator.services.mozilla.com/D135162
The Runnable markers in the profilers are handy, but miss many types of
runnables. This includes most of those that wrap another runnable and run that
at a (possibly) later time.
AbstractThread, TaskDispatcher and TaskQueue does this for e.g. tail dispatched
tasks.
TaskQueueWrapper does this when wrapping webrtc tasks (and Mozilla Runnables) to
be run in a Mozilla TaskQueue with some overhead on the stack.
DelayedRunnable wraps a runnable to be run after a timeout.
It would perhaps be better in many cases to ignore the intermediate runnables,
but I haven't seen a straight forward way to achieve this.
More detailed data could be added on a case by case basis, for instance the
delay for a DelayedRunnable (incl. actual vs. target delay) or the scope of a
task in which a tail-dispatched runnable was dispatched. But this is also true
for the status quo (for instance the time from dispatch to run) so I leave these
ideas as future work.
Differential Revision: https://phabricator.services.mozilla.com/D135027
The Runnable markers in the profilers are handy, but miss many types of
runnables. This includes most of those that wrap another runnable and run that
at a (possibly) later time.
AbstractThread, TaskDispatcher and TaskQueue does this for e.g. tail dispatched
tasks.
TaskQueueWrapper does this when wrapping webrtc tasks (and Mozilla Runnables) to
be run in a Mozilla TaskQueue with some overhead on the stack.
DelayedRunnable wraps a runnable to be run after a timeout.
It would perhaps be better in many cases to ignore the intermediate runnables,
but I haven't seen a straight forward way to achieve this.
More detailed data could be added on a case by case basis, for instance the
delay for a DelayedRunnable (incl. actual vs. target delay) or the scope of a
task in which a tail-dispatched runnable was dispatched. But this is also true
for the status quo (for instance the time from dispatch to run) so I leave these
ideas as future work.
Differential Revision: https://phabricator.services.mozilla.com/D135027
Calling NSS_IsInitialized() off the main thread caused intermittent tsan failures because NSS_IsInitialized() reads global variable nssIsInitted without acquiring the nssInitLock lock.
During Firefox startup, about 1000 nsIDs are generated, but only about 10 are generated off the main thread, so this change has very little impact on how often nsID::GenerateUUID() will use NSS's RNG. Of the nsIDs generated on the main thread during startup, about 600 are generated before NSS is initialized (so they use MFBT's RNG) and 400 are generated after NSS is initialized.
After Firefox reaches a steady state, loading a light web page like google.com generates about 300 nsIDs and a heavy web page like cnn.com generates about 2000 nsIDs. All these nsIDs are generated on the main thread using NSS's RNG.
Differential Revision: https://phabricator.services.mozilla.com/D134233
Calling NSS_IsInitialized() off the main thread caused intermittent tsan failures because NSS_IsInitialized() reads global variable nssIsInitted without acquiring the nssInitLock lock.
During Firefox startup, about 1000 nsIDs are generated, but only about 10 are generated off the main thread, so this change has very little impact on how often nsID::GenerateUUID() will use NSS's RNG. Of the nsIDs generated on the main thread during startup, about 600 are generated before NSS is initialized (so they use MFBT's RNG) and 400 are generated after NSS is initialized.
After Firefox reaches a steady state, loading a light web page like google.com generates about 300 nsIDs and a heavy web page like cnn.com generates about 2000 nsIDs. All these nsIDs are generated on the main thread using NSS's RNG.
Differential Revision: https://phabricator.services.mozilla.com/D134233
While mingw builds don't require user32 and advapi32 explicitly, it doesn't
hurt for them to be there (and they're required for clang-cl build).
Likewise, while clang-builds don't require uuid and userenv explicitly
because they're pulled in via #pragmas in the source code, mingw doesn't
support those #pragmas and needs them explicitly, which doesn't hurt the
clang-cl builds.
Differential Revision: https://phabricator.services.mozilla.com/D134737
While mingw builds don't require user32 and advapi32 explicitly, it doesn't
hurt for them to be there (and they're required for clang-cl build).
Likewise, while clang-builds don't require uuid and userenv explicitly
because they're pulled in via #pragmas in the source code, mingw doesn't
support those #pragmas and needs them explicitly, which doesn't hurt the
clang-cl builds.
Differential Revision: https://phabricator.services.mozilla.com/D134737
The goal of this event is for doing hit testing in content and emit an
accessibility event with the result for Android's explore by touch.
This event allows us to use APZ's ability to target the correct content
doc.
Differential Revision: https://phabricator.services.mozilla.com/D132840
Randell Jesup
Masatoshi Kimura
Gabriele Svelto
Nika Layzell
Mike Hommey
Noemi Erli
criss
Mike Conley
kriswright
Emilio Cobos Álvarez
Alexandre Lissy
Paul Zuehlcke
Jan de Mooij
Yury Delendik
Neil Deakin
Ting-Yu Lin
Alexandru Michis
Mozilla Releng Treescript
Cristian Tuns
Andreas Pehrson
Butkovits Atila
Chris Peterson
Iulian Moraru
Andreea Pavel
Eitan Isaacson
Bobby Holley