This patch does two things:
1) Adds a few new pieces of information to the installation "first_seen" event. Specifically:
* other_inst - true when any non-MSIX installation other than the running one was present when this event was prepared
* other_msix_inst - true when any MSIX installation other that the running one was present when this event was prepared
2) Begins sending this event for MSIX installations
Differential Revision: https://phabricator.services.mozilla.com/D134326
Based on our experience with Firefox for Android, annotating Glean metrics
with issue tracker component information can provide valuable context to
anyone searching for metrics.
This adds a new set of tags corresponding to the components in the
tree, annotates the existing Glean metrics. Finally, it also adds a new
mach command called `update-glean-tags` to update the tags files based
on build metadata.
Differential Revision: https://phabricator.services.mozilla.com/D134332
Based on our experience with Firefox for Android, annotating Glean metrics
with issue tracker component information can provide valuable context to
anyone searching for metrics.
This adds a new set of tags corresponding to the components in the
tree, annotates the existing Glean metrics. Finally, it also adds a new
mach command called `update-glean-tags` to update the tags files based
on build metadata.
Differential Revision: https://phabricator.services.mozilla.com/D134332
This caches the top-sites context like we cache other contexts. The cache is
cleared when the top sites change or are enabled/disabled.
Unlike other contexts, which are evicted from the cache once too many newer
contexts are cached, the top-sites context is never evicted due to space reasons
because showing the top sites is a frequent action.
I wanted to keep the logic around when/whether the top sites have changed or
been enabled/disabled isolated to the top-sites provider, since it's the class
concerned with top sites in the first place, instead of spreading it out to
`QueryContextCache`. However, by the same token I didn't want to cache contexts
directly in the provider in order to keep all context caching in
`QueryContextCache`. (Contexts are also per window/urlbar, not global, so if we
were to cache contexts in the provider, we'd need to store them in map from
windows to contexts or something similar.)
So I added a more general listener system to the provider. Listeners are called
when the top sites change or they are enabled/disabled. `QueryContextCache` adds
a listener function so it can evict its cached top-sites context. The provider
keeps weak references to the listener functions because currently `UrlbarView`
doesn't have a way to tell when it's destroyed, so it doesn't know when it
should remove listeners.
Finally, there doesn't seem to be a way to observe the `TopSitesFeed` from the
outside, and I don't think it's the role of `TopSitesFeed` to broadcast an
observer message to the entire browser or something like that, so I modified
`AboutNewTab` to subscribe to changes in its activity stream object and then
compare the new top sites to the last seen top sites, and if they're different,
then broadcast a new "newtab-top-sites-changed" notification.
Differential Revision: https://phabricator.services.mozilla.com/D134863
TabUnloader.jsm can directly call windowGlobal.hasActivePeerConnections(),
so windowContext.hasActivePeerConnections is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D132654
This patch makes sure the Tab Unloading feature does not unload tabs that have
active peer connections not to disrupt browsing experience based on WebRTC peer
connections.
To enable JS code to access the number of active peer connections, this patch
moves `nsPIDOMWindowInner::mTotalActivePeerConnections` to `WindowGlobalParent`.
Differential Revision: https://phabricator.services.mozilla.com/D128761
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
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
