- record number of saved tab groups
- record min/max/median/average number of tabs in saved tab groups
This patch adds a new observable topic `sessionstore-saved-tab-groups-changed` to SessionStore. This is emitted when a saved tab group is added or removed from the session. BrowserUsageTelemetry subscribes to that topic and updates saved tab group-related metrics.
BrowserUsageTelemetry is also setting those saved tab group-related metrics on startup. BrowserGlue initializes BrowserUsageTelemetry after the session has been restored/set up, so saved tab group information will be available at that time. This is also important to make sure that we keep this metric correct even if a user doesn't touch their saved tab groups during the course of a session.
Differential Revision: https://phabricator.services.mozilla.com/D245138
When using the tab context menu or drag-dropping tabs to put them into a group, record a metric for the number of tabs added to the group.
Data Science asked us to launch with this metric disabled so that they could control it using server knobs. They expect a high volume of events, so they expect to only enable this metric for some proportion of users.
I converted the existing `TabMove` event derived from `UIEvent` being fired when tabs change their tab index in the tab strip. `UIEvent` doesn't allow for attaching additional context/detail to the event. `TabMove` is now a `CustomEvent` that provides more context about the moved tab and it fires in more cases -- it's possible for the tab index not to change despite the tab having "moved" into/out of a tab group.
This approach would not capture tab movements that occur across multiple frames/event loop iterations.
Differential Revision: https://phabricator.services.mozilla.com/D244616
SessionStore wants to flush the window and tab status early enough to not be disturbed by things going down, that is in response to "quit-application-granted".
Previously we used the AsyncShutdown blocker quitApplicationGranted here, but that is deprecated as it's not a "real" shutdown phase and caused a loot of confusion elsewhere.
Given we already had our own timer to actually avoid the crash from AsyncShutdown, there is no point in using AsyncShutdown and we can just spin the event loop by ourselves here.
Differential Revision: https://phabricator.services.mozilla.com/D242658
This is what UX has decided makes sense, and will be much less disruptive
than dimming out all favicons on session restore. When we're ready the
default value of "browser.tabs.fadeOutExplicitlyUnloadedTabs" will be
true, and the default value of "browser.tabs.fadeOutUnloadedTabs" will
remain false.
Differential Revision: https://phabricator.services.mozilla.com/D241481
* We retain the behavior from legacy sidebar which re-opens the previously open sidebar panel when the sidebar is toggled open
* Rename SidebarState's '#previousLauncherVisible' to '#previousLauncherExpanded' as it actually tracks expandedness
* Don't persist the panel/command id when the panel isn't open
* Ensure all the sidebar tests reset the sidebar state when they are done
Differential Revision: https://phabricator.services.mozilla.com/D234773
When closing single or multiple tabs, session state has historically capped the number of closed tabs being tracked. The main motivation was to prevent session file sizes on disk from getting too large.
When we introduced tab groups to session state, we avoided those caps when the tab group itself is being closed/saved. Users think of tab groups as whole entities. We were successfully saving tab groups with any number of tabs.
I introduced a regression causing closed tab groups and saved-and-closed tab groups to have their tab lists in session state capped. This patch resolves the regression by bypassing the cap when a closing tab is being closed as part of a tab group closing as a whole. Single or multiple tabs that are closed directly by the user should still be capped even if those tabs were in a tab group.
Differential Revision: https://phabricator.services.mozilla.com/D241087
* We retain the behavior from legacy sidebar which re-opens the previously open sidebar panel when the sidebar is toggled open
* Rename SidebarState's '#previousLauncherVisible' to '#previousLauncherExpanded' as it actually tracks expandedness
* Don't persist the panel/command id when the panel isn't open
* Ensure all the sidebar tests reset the sidebar state when they are done
Differential Revision: https://phabricator.services.mozilla.com/D234773
* We retain the behavior from legacy sidebar which re-opens the previously open sidebar panel when the sidebar is toggled open
* Rename SidebarState's '#previousLauncherVisible' to '#previousLauncherExpanded' as it actually tracks expandedness
* Don't persist the panel/command id when the panel isn't open
* Ensure all the sidebar tests reset the sidebar state when they are done
Differential Revision: https://phabricator.services.mozilla.com/D234773
* We retain the behavior from legacy sidebar which re-opens the previously open sidebar panel when the sidebar is toggled open
* Rename SidebarState's '#previousLauncherVisible' to '#previousLauncherExpanded' as it actually tracks expandedness
* Don't persist the panel/command id when the panel isn't open
* Ensure all the sidebar tests reset the sidebar state when they are done
Differential Revision: https://phabricator.services.mozilla.com/D234773
