Replace the use of pinned atoms with code to trace all atoms stored in live
XPCNativeInterface instances. This means we stop 'leaking' those atoms after
releasing the XPCNativeInterface using them.
Differential Revision: https://phabricator.services.mozilla.com/D132693
The basic part of the infrastructure of scroll-linked animations. This is
designed based on scroll-linked animation generated by CSS. We will
implement the timing computation and hook the ScrollTimeline to the CSS
animations in the following patches.
All the tests are in the patch that hooks ScrollTimeline to CSS Animation.
Differential Revision: https://phabricator.services.mozilla.com/D129100
This patch contains changes to moz_task to improve it's support for
async execution on multiple threads. Unlike the previous executor
implementation, this new implementation reduces the amount of unsafe
code substantially by depending on the async-task crate
(https://crates.io/crates/async-task) for the core task implementation.
This adds a few additional features:
* Both local (no Send bound) and non-local (with Send bound) execution support,
* Support for spawning on arbitrary nsIEventTargets or the background task pool,
* Returned Task objects from runnables which may be .await-ed on or detach()-ed,
* Support for spawning with the NS_DISPATCH_EVENT_MAY_BLOCK flag set,
* Automatic use of NS_DISPATCH_AT_END when required,
* Support for specifying the runnable priority for runnables.
There are also some correctness improvements, and exposed a better API
for dispatching normal runnable functions to background threads.
After these changes the TaskRunnable API should no longer be necessary.
It is re-implemented on top of the executor and kept in-place to avoid
rewriting all consumers.
Differential Revision: https://phabricator.services.mozilla.com/D130705
This introduces a low memory watcher that dispatches an offthread read of /proc/meminfo every 5000/1000ms depending on memory levels, then determines which information to act on. It works like this:
- Get a percentage of `MemAvailable` versus `MemTotal`.
- If memory drops below 5% availability, we are in a memory pressure scenario
- If `MemAvailable` is not large enough to accommodate a content process, we are in a memory pressure scenario
- If we are in a memory pressure scenario, notify the observers from the main thread.
The value I decided to use to represent a content process was based on observation and should be adjusted if it is not representative of what we consider a "typical" content process.
Differential Revision: https://phabricator.services.mozilla.com/D117972
This introduces a low memory watcher that dispatches an offthread read of /proc/meminfo every 5000/1000ms depending on memory levels, then determines which information to act on. It works like this:
- Get a percentage of `MemAvailable` versus `MemTotal`.
- If memory drops below 5% availability, we are in a memory pressure scenario
- If `MemAvailable` is not large enough to accommodate a content process, we are in a memory pressure scenario
- If we are in a memory pressure scenario, notify the observers from the main thread.
The value I decided to use to represent a content process was based on observation and should be adjusted if it is not representative of what we consider a "typical" content process.
Differential Revision: https://phabricator.services.mozilla.com/D117972
This introduces a low memory watcher that dispatches an offthread read of /proc/meminfo every 5000/1000ms depending on memory levels, then determines which information to act on. It works like this:
- Get a percentage of `MemAvailable` versus `MemTotal`.
- If memory drops below 5% availability, we are in a memory pressure scenario
- If `MemAvailable` is not large enough to accommodate a content process, we are in a memory pressure scenario
- If we are in a memory pressure scenario, notify the observers from the main thread.
The value I decided to use to represent a content process was based on observation and should be adjusted if it is not representative of what we consider a "typical" content process.
Differential Revision: https://phabricator.services.mozilla.com/D117972
To do this, we always draw the native titlebar behind the toolbox, and
then make the toolbox adapt to it by using the titlebar radius. This
makes us preserve the shadow properly.
On Wayland we'd double-draw the shadow (see bug 1509931 comment 4) so
this fixes it by trimming it as well using border-radius.
Differential Revision: https://phabricator.services.mozilla.com/D128681
This allows us to move away from using IsNavigating field in parent-controlled
paths. Use a new distinct error code in cases when we cancel loads in
Canonical BC due to another load starting. This way, we know to not reset the
urlbar if we are doing another load.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1721217#c10 for longer
explanation of what is going on here.
Differential Revision: https://phabricator.services.mozilla.com/D126845
This is based off work by smurfd. But this patch doesn't support buttons
both at the left and right, which simplifies a lot the implementation.
Also, clean-up the existing env variables while at it.
Co-authored-by: Nicklas Boman <smurfd@gmail.com>
Differential Revision: https://phabricator.services.mozilla.com/D132073
This allows us to move away from using IsNavigating field in parent-controlled
paths. Use a new distinct error code in cases when we cancel loads in
Canonical BC due to another load starting. This way, we know to not reset the
urlbar if we are doing another load.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1721217#c10 for longer
explanation of what is going on here.
Differential Revision: https://phabricator.services.mozilla.com/D126845
Those AllocReplacement tests have been going intermittent on and off for
a while. See bug 1556754, bug 1554330, bug 1475411, bug 1544926, bug
1732998, bug 1730436.
The last non-whitespace change to the test file was bug 1433015 which
was filed for the exact same problem, but the patch didn't actually do
what it was advertizing to be doing: adding "DeathTest" to the test
names doesn't turn them into death tests.
Actually turning them into death tests doesn't fix the tests either, in
fact, it would tend to make things worse because death tests run in a
subprocess, and that subprocess runs a bunch of initialization code
including initializing threads, and all the initialization code adds
chances to race with these threads.
I'm not sure exactly why bug 1696504 makes things worse, but overall,
the problem is that these tests assume they are alone running, but they
aren't, and allocations/deallocations happening in other threads do
break the tests (IOW, the comment saying that it doesn't seem to be a
problem in practice is unfortunately wrong or outdated).
Since bug 1254779, which added these tests, things have changed, though,
and we now have another way to validate whether an allocation comes from
jemalloc or not.
Also completely disable the test when not building with jemalloc because
it's not doing anything useful (and jemalloc_ptr_info is not available
in that case).
Differential Revision: https://phabricator.services.mozilla.com/D131999
We suspect to see the parent processes annotation on crash reports from child processes that result from IPC shutdown kills. In order to reduce the confusion we add a prefix for the process type.
Differential Revision: https://phabricator.services.mozilla.com/D131719
This stops destructing the stencils held by ScriptPreloader on release build,
to avoid the shutdown hang caused by thrashing.
Also:
* Move ScriptPreloader::Cleanup from xpcom-shutdown notification to ScriptPreloader destructor, given there's no reason for having 2 steps
* Replace ClearOnShutdown call with explicit function call for the singleton deletion, for simplicity
* Remove now-unused PostJSShutDown phase
Differential Revision: https://phabricator.services.mozilla.com/D130839