Test-only fix: pref-on tab unloading and memory-pressure notifications when the test is run on beta or release. Tab unloading and memory pressure notifications are limited to Nightly at this time.
Differential Revision: https://phabricator.services.mozilla.com/D129665
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
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
- Updated PermissionUI prompt test to also test permission states for prompts which do not use the permission manager
- Also do permission panel checks in storageAccessDoorhanger for block state
Differential Revision: https://phabricator.services.mozilla.com/D127962
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
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
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 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
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
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 builds on D111205 by factoring out some initialization into a new
`initPageActionsTest()` in head.js. I'll need to use it in
browser_PageActions_newWindow.js too (bug 1703389).
Pre-Proton, there are 4 page action context menu items:
* Add to Address Bar
* Remove from Address Bar
* Manage Extension
* Remove Extension
Regardless of Proton, there are two context menus, one for buttons in the urlbar
and one for items in the page action panel. They're actually the same menu of
course.
This test currently checks each menu item in both context menus for a
non-built-in action except for the Remove Extension menu item. In Proton, we
don't need to check Add or Remove, so I modified the test to skip them. I also
added a check for the Remove Extension menu item. The test now must actually
create an extension with a page action to test the context menu because in
Proton only actions with extension IDs get the context menu (bug 1700364). Since
the test is creating an extension anyway, testing the Remove Extension menu item
isn't too hard.
Depends on D111205
Differential Revision: https://phabricator.services.mozilla.com/D111222
Removes NPAPI plugin features from tests outside of dom/plugins. Some tests are updated to avoid NPAPI behavior and others are deleted if they no longer offer anthing useful.
Differential Revision: https://phabricator.services.mozilla.com/D107134
Removes NPAPI plugin features from tests outside of dom/plugins. Some tests are updated to avoid NPAPI behavior and others are deleted if they no longer offer anthing useful.
Differential Revision: https://phabricator.services.mozilla.com/D107134
The widget is only added if screenshots are enabled (similar behavior to the fxa
toolbar button).
Button must take into account onLocationChange due to the fact that screenshots
extension is not available on about pages.
Adds a test for the disabled state, with more screenshot tests intended in the future
Differential Revision: https://phabricator.services.mozilla.com/D107727
The IDs of actions pinned to the urlbar are kept in
`PageActions._persistedActions.idsInUrlbar`. To pin all actions to the urlbar,
theoretically all we need to do is add all action IDs to this array, and things
should just work. PageActions already has a migration mechanism that could check
if Proton is enabled and add all the action IDs if it is. However, that would
mean that if Proton were subsequently disabled, or if the user downgraded to a
Firefox without Proton, they'd end up with all their actions still in the
urlbar. They could remove them one by one so it's not a big problem, but it
would be annoying.
Instead, this patch keeps two arrays of urlbar IDs. One stashes the user's
original pinned actions and PageActions never touches it as long as Proton is
enabled, and the other is the usual array that happens to have the IDs of all
the actions when Proton is enabled.
Depends on D107763
Differential Revision: https://phabricator.services.mozilla.com/D107600
See bug for more details, but effectively the decision is to show the same
notification which we would normally show for hung pages if an iframe hangs,
but only do so if the user is trying to interact with content hung by that
iframe. This should accomplish that.
Differential Revision: https://phabricator.services.mozilla.com/D107933
