The only difference between the icon that was removed and the one kept is that
the removed one has a default fill color in the SVG. This meant everywhere the
icon was replaced, we have to make sure that a fill color is defined in CSS.
In a few cases, that necessitated adding a new class. In a few others, colors
were already being defined for the icon, so there was no need to add any here.
Differential Revision: https://phabricator.services.mozilla.com/D121030
We have the pref `browser.tabs.unloadOnLowMemory` to turn on the tab unloading
feature. Since it controlled whether we initialize the memory watcher or not
in `TabUnloader.init()`, changing it required process start.
To conduct A/B testing for this feature, our infrastructure needs to be able
to change the pref in the middle of session. So this change moves the pref
check from `TabUnloader.init()` to `TabUnloader.unloadTabAsync()`. With this,
we fully exercise the memoruy watcher regardless of the pref's value, but invokes
tab unloading only when the pref is on.
Differential Revision: https://phabricator.services.mozilla.com/D120744
The new histogram `TAB_UNLOAD_TO_RELOAD` records how long a tab had been
unloaded until it was reload by a user. With this data, we can evaluate
the selection logic to choose a tab to unload. For example, if many of
unloaded tabs are reloaded within 30 seconds or so, we unload a wrong tab.
Differential Revision: https://phabricator.services.mozilla.com/D120019
This patch disables the update service as if it were disabled by policy
whenever a package identify is present. User interfaces are treated as if
the updater had not been included in the build, because that prevents any of
our usual update UI from being shown, and in particular ensures that we do not
generate messages about an administrator handling updates, as would normally
happen when disabling updates via policy.
The telemetry environment's update.enabled flag is deliberately left alone in
this patch, because the mere fact of using an app package does not really say
anything about whether the user intends to allow automatic updating or not.
Depends on D114427
Differential Revision: https://phabricator.services.mozilla.com/D114886
This patch disables the update service as if it were disabled by policy
whenever a package identify is present. User interfaces are treated as if
the updater had not been included in the build, because that prevents any of
our usual update UI from being shown, and in particular ensures that we do not
generate messages about an administrator handling updates, as would normally
happen when disabling updates via policy.
The telemetry environment's update.enabled flag is deliberately left alone in
this patch, because the mere fact of using an app package does not really say
anything about whether the user intends to allow automatic updating or not.
Differential Revision: https://phabricator.services.mozilla.com/D114886
See discussion in the last few comments on the bug. If we don't wait for the correct URL
to load in the browser, the SpecialPowers.spawn task can get aborted, which causes the
test to fail.
Differential Revision: https://phabricator.services.mozilla.com/D119518
This is the main part to address bug 1701368.
Before this patch, `nsAvailableMemoryWatcher` directly broadcasted a memory-pressure
event when we enter into a low-memory situation and `TabUnloader` unloaded a tab in
response to the memory-pressure message. We want to decouple `TabUnloader` from
memory-pressure listeners because unloading a tab may solve a low-memory situation
alone.
With this patch, if `nsAvailableMemoryWatcher` detects a low-memory situation,
it invokes `TabUnloader` synchronously via an XPCOM interface. If `TabUnloader`
unloads a tab, we don't do any further action. If there is no discardable tab,
`TabUnloader` notifies back `nsAvailableMemoryWatcher` via another XPCOM interface,
so that `nsAvailableMemoryWatcher` can notify of a memory-pressure event.
Differential Revision: https://phabricator.services.mozilla.com/D117673
This patch introduces an XPCOM object which is represented by the single instance of
`nsAvailableMemoryWatcherBase` so that `nsAvailableMemoryWatcher` can synchronously
access `TabUnloader`.
We currently implement a watcher class for Windows only. For other platforms, what
we need to do is to define a class inherinting `nsAvailableMemoryWatcherBase` and
a simple factory method `CreateAvailableMemoryWatcher()` returning an instance of
that class.
Differential Revision: https://phabricator.services.mozilla.com/D118393
This is the main part to address bug 1701368.
Before this patch, `nsAvailableMemoryWatcher` directly broadcasted a memory-pressure
event when we enter into a low-memory situation and `TabUnloader` unloaded a tab in
response to the memory-pressure message. We want to decouple `TabUnloader` from
memory-pressure listeners because unloading a tab may solve a low-memory situation
alone.
With this patch, if `nsAvailableMemoryWatcher` detects a low-memory situation,
it invokes `TabUnloader` synchronously via an XPCOM interface. If `TabUnloader`
unloads a tab, we don't do any further action. If there is no discardable tab,
`TabUnloader` notifies back `nsAvailableMemoryWatcher` via another XPCOM interface,
so that `nsAvailableMemoryWatcher` can notify of a memory-pressure event.
Differential Revision: https://phabricator.services.mozilla.com/D117673
This patch introduces an XPCOM object which is represented by the single instance of
`nsAvailableMemoryWatcherBase` so that `nsAvailableMemoryWatcher` can synchronously
access `TabUnloader`.
We currently implement a watcher class for Windows only. For other platforms, what
we need to do is to define a class inherinting `nsAvailableMemoryWatcherBase` and
a simple factory method `CreateAvailableMemoryWatcher()` returning an instance of
that class.
Differential Revision: https://phabricator.services.mozilla.com/D118393
Rather than adding a new scalar I'm just filing the toolbar context menu's tab-related items
under the tab context menu. The use of other items - customization options like
showing/hiding toolbars and adding/removing buttons - are already covered by other event
telemetry, and this will help group similar items together.
Differential Revision: https://phabricator.services.mozilla.com/D115640
Luminance goes from 0 to 255, so using 127 makes sense, and allows all
disabled titlebar colors that I found in various GTK themes to still be
considered dark enough (for those, 110 was too low).
Differential Revision: https://phabricator.services.mozilla.com/D114876
HangData is the only member left in the union and SLOW_SCRIPT is the only member left in the enum.
This patch also migrates the one remaining (invalid) use of PLUGIN_HANG in testing to work as a SLOW_SCRIPT instead.
Differential Revision: https://phabricator.services.mozilla.com/D113885
