Kingsoft's modules are injected before `IOInterposer` and starts a thread that
calls `NtReadFile`. It conflicts with the main thread where `IOInterposer` hooks
`NtReadFile`.
This patch is a mitigation until we make `IOInterposer` compatible with such
third-party injections (bug 1646804).
Differential Revision: https://phabricator.services.mozilla.com/D129876
We want to be able to have a different behavior for interactions with an entry
in the Windows system tray - specifically, we want to be able to open a window
on left click, and show a menu on right click. This patch allows us to control
this with a "contextmenu" attribute on the menu passed in to `AddItem`, and
receive a "systemstatusbarclick" event in the case of a left click.
Regarding tests, I don't know that we have a good way of testing this?
Suggestions are of course welcome here.
Differential Revision: https://phabricator.services.mozilla.com/D129413
mozalloc_abort() implies OOM. NS_DebugBreak() is used for other debug breaks and aborts. Calling MOZ_CRASH_UNSAFE(aMsg) instead of MOZ_CRASH() is unlikely to cause new OOM crashes because NS_DebugBreak() already did a lot of work to format aMsg and walk the stack before calling Abort() and MOZ_CRASH_UNSAFE(aMsg).
Differential Revision: https://phabricator.services.mozilla.com/D129116
To more properly support Linux having a different default at runtime.
Expose the resolved value in appinfo for convenience, and use it in the
front-end as needed.
Differential Revision: https://phabricator.services.mozilla.com/D129004
jemalloc_stats takes an array for its second argument. It expects this
array to have enough space for all the bins, previously the maximum was set
as a magic number. To make it dependent on the configured bins this patch
replaces the compile-time constant with a function.
Differential Revision: https://phabricator.services.mozilla.com/D127761
Enable tab unloading on macOS when the OS memory pressure level reaches "critical".
Add a gtest that exercises the memory pressure response by testing that a tab unload attempt occurs and the internal memory-pressure notification is sent. Test does not cause a real OS memory pressure event.
Use the memory_pressure(1) macOS command to generate artificial memory pressure events to test the browser response. For example, the following artificially puts the OS in the "critical" memory pressure level for 60 seconds.
`$ sudo memory_pressure -S -l critical -s 60`
Differential Revision: https://phabricator.services.mozilla.com/D126560
Tab unloading should not unload "fresh" tabs i.e. tabs that were accessed
very recently, even though one of them was the least recently used tab.
To achieve it, this patch introduces the minimum inactive duration and we
prevent tabs that were accessed in the last period of that duration from
being unloaded.
This patch sets the default value to 10 minutes based on the historgram
`TAB_UNLOAD_TO_RELOAD` where the median was 60sec and the 75th percentile
was 1040sec. This value can be overriden by the parameter of the TabUnloader's
APIs so that about:unloads and the tests can unload those fresh tabs.
Differential Revision: https://phabricator.services.mozilla.com/D125824
The product experience migrating a profile when a non-MSIX Firefox is
running is not ideal, so we're going to always start with a fresh
profile for simplicity.
This is a straight backout of the "meat" of Bug 1709969 - Migrate from
an existing profile when running from an app package for the first
time, namely `hg backout -r 5136d2f684012dc3d586dcb10374f8c6eda8b6d7`.
The changes from follow-up Bug 1723298 (correcting test failures on
devedition), namely revision a4bca433c8f7003a90fda61248f38d9b389c394e,
were manually reverted and the test files deleted.
Differential Revision: https://phabricator.services.mozilla.com/D129066
`profiler_add_marker()` now checks if the marker's target thread is actively being profiled. This is to prevent adding markers that would be discarded anyway, from taking CPU time to process, and from using space in the profile buffer.
This means that `profiler_thread_is_being_profiled(ProfilerThreadId)` must be used when a marker is intended for another thread, i.e., when it uses the MarkerThreadId option.
(Note: since baseprofiler::profiler_thread_is_being_profiled(ProfilerThreadId) is not available, baseprofiler::AddMarker cannot prevent markers targetted at non-profiled thread; There are none yet anyway.)
Differential Revision: https://phabricator.services.mozilla.com/D128576
We always use alpha visual for WebRender, and appearance: none is
unnecessary (root element has no intrinsic appearance).
Differential Revision: https://phabricator.services.mozilla.com/D128682
For the same reasons discussed in the previous commit, it's impractical
to join these threads on shutdown, and so we should suppress thread leak
reports for them.
Differential Revision: https://phabricator.services.mozilla.com/D128651
This thread waits on a syscall for the completion of an
asynchronously-spawned process. Since there's no general guarantee that
Gecko will outlive the proccesses it spawns, this thread can continue
running all the way up until the process terminates. And while we
generally endeavor to have teardown logic join any spawned threads, we
don't have an easy way to interrupt the platform-specific routines that
the thread might be waiting on.
That leaves us with instrumenting the profiler code to handle APIs
arbitrarily late during shutdown (i.e. after static destructors have
run), or simply not registering the thread with the profiler. The latter
is much simpler, and doesn't cost us much because these threads never do
any interesting computation, and thus aren't likely to be relevant to
the profiler. This registration was added in bug 1323100, which was just
a grep-driven activity which didn't identify any particular need for
profiling this thread.
Differential Revision: https://phabricator.services.mozilla.com/D128532