I want to be able to check if the update-available notification is fired during testing. The entry point to firing that notification is UpdateService.onCheckComplete, but it currently kicks off its work and does not wait for it to finish. This means that I can wait for the update-available notification to be fired, but I cannot easily wait for it NOT to be fired, which is what I want to be able to test here.
It looks though like it should be easy enough to just convert this interface to an asynchronous one. This will make it much easier to call onCheckComplete and know by the end of it if the update-available notification gets fired or not.
Differential Revision: https://phabricator.services.mozilla.com/D126162
This test was brittle for a few reasons:
1. The bookmarks toolbar is, by default, configured to show and hide
depending on whether or not about:home/about:newtab is displayed.
This meant that sometimes when trying to click on a bookmark
toolbar item, a transition from the visible-to-collapsed or
collapsed-to-visible state would be underway, and the click
event would ultimately miss its mark.
2. The bookmarks toolbar also populates itself lazily, so the test has
been adjusted to ensure that there are items in the toolbar before
it attempts to click on one.
Differential Revision: https://phabricator.services.mozilla.com/D125761
These tests are excluded from android test runs in moz.build. Including
an explicit annotation in each manifest avoids scheduling confusion.
browser-chrome and plain-chrome tests in browser/ are of no concern,
since those test types are never scheduled on android.
Differential Revision: https://phabricator.services.mozilla.com/D125266
The page contains
- a table to show the tabs and their attributes that `TabUnloader` considers
- a button to trigger `TabUnloader.unloadLeastRecentlyUsedTab()`
to visualize the behavior of `TabUnloader` and manually trigger it.
Differential Revision: https://phabricator.services.mozilla.com/D123988
The patch includes the following updates:
- getAllProcesses() adds a per-tab map to hold the processes backed by
the process to a tab so that we don't need to iterateprocesses twice.
- Consider a process that hosts multiple frames in a single tab as
a unique process because such processes are terminated when
that single tab is unloaded.
- Add `TabUnloader.isDiscardable()`
Differential Revision: https://phabricator.services.mozilla.com/D123986
about:newtab doesn't load aboutPrivateBrowsing.ftl and conversely about:privatebrowsing doesn't load newtab.ftl. Since permanent private browsing mode uses about:newtab as its new tab, we need to make sure we load our strings from newtab.ftl in that case.
Differential Revision: https://phabricator.services.mozilla.com/D121646
Similar to CONTENT_PROCESS_COUNT, but enumerated instead of ranged.
Also fixes a typo which resulted in us not clearing the timer on uninit.
Differential Revision: https://phabricator.services.mozilla.com/D121134
This patch removes the `extensions.webextPermissionPrompts` pref as well as
`permissionPromptsEnabled` prop on `mozAddonManager`.
While working on this patch, we noticed that some of the `browser_webapi.js`
weren't testing anything for a while now. That has been fixed. In addition,
the `test_blocklistchange.js` file has been updated to handle the permissions
prompt.
Differential Revision: https://phabricator.services.mozilla.com/D121114
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
This will allow detecting the system theme, which allows fixing some of
the blocked bugs.
Note that when using the system theme we will still match light or dark
appropriately, so this shouldn't change behavior just yet.
Differential Revision: https://phabricator.services.mozilla.com/D113516
Stop supporting toolbar_field_separator in themes. We have no more
vertical separators in toolbar fields, and it could hide functional horizontal
separators in the urlbar panel, because it was misused there.
Introduce an autocomplete_popup_separator experimental color instead and use
a color-mix of currentColor to better adapt to LWT theme colors.
Differential Revision: https://phabricator.services.mozilla.com/D112616
This adds a new @media query -moz-toolbar-prefers-color-scheme which works like
prefers-color-scheme but is set based on the browser theme rather than the OS
theme. The background colour of the toolbar is used to determine the theme
dark/light preference. This will be used for in-content common.css pages and
other UI elements that include that stylesheet in the browser-chrome through
shadow DOM.
The end result is that about: pages, infobars, and modals will now "match" the
browser theme (just light/dark mode, not LWT theming support).
Differential Revision: https://phabricator.services.mozilla.com/D111486
Mirko Brodesser
Michelle Goossens
Gijs Kruitbosch
Kirk Steuber
Mike Conley
Neil Deakin
Narcis Beleuzu
Florian Quèze
Harry Twyford
Geoff Brown
Mark Banner
Noemi Erli
Toshihito Kikuchi
Iulian Moraru
Johann Hofmann
Ben Hearsum
Kajal Sah
Nika Layzell
Kashav Madan
William Durand
Molly Howell
Christoph Kerschbaumer
Sandor Molnar
Luz De La Rosa
Barret Rennie
Csoregi Natalia
Paul Zuehlcke
Butkovits Atila
Dorel Luca
Andrew Osmond
Brindusan Cristian
Alexandru Michis
Ed Lee
Julian Descottes
Bryce Seager van Dyk
Emilio Cobos Álvarez
David Parks
Valentin Gosu
Emma Malysz
Cosmin Sabou
Joel Maher
Marco Bonardo
Mark Striemer