- Add the schema itself with definitions for the various data structures the serialized browser
session state contains
- Add means of validating the current state against the schema with a new SessionStore.vaidateState
method
- Add a smoke test to the schema by validating against sample session restore document
- Fix an issue in SidebaState which was returning undefined for some property values which isn't valid JSON
Differential Revision: https://phabricator.services.mozilla.com/D246163
Records counts of user interactions with tab groups:
- expand a collapsed tab group
- collapse an expanded tab group
- rename a tab group
- change a tab group's color
- save and close a tab group
- delete a tab group
- reopen a deleted tab group
- ungroup a tab group
- move a tab group to a new window
- reopen a saved and closed tab group from the list all tabs menu
- reopen a saved and closed tab group from a URL bar suggestion
- reopen a recently closed tab group from the recently closed tabs menu
Differential Revision: https://phabricator.services.mozilla.com/D246123
Current behavior on Windows: if you close a window that has open tab groups, the tab groups are automatically saved. Opening Firefox into the initial deferred restore state properly shows the tab groups as saved. However, after restoring the previous session manually, the tab groups exist both in the tab strip (correct) and in the list of saved tab groups (incorrect).
Bug 1950611 and bug 1954488 dealt with several edge cases around saved groups + session restore. In Windows, it looks like on session startup, `_prepDataForDeferredRestore` receives a state where the open tab groups from last session are stored in both `savedGroups` and `windows[].groups[]`. `_prepDataForDeferredRestore` has logic to convert the open tab groups in `windows[].groups[]` into saved groups, but it'll skip any that are already present in the list of saved groups. This was fine until the fix for bug 1954488, which unsets `removeAfterRestore` from the saved group; the `windows[].groups[]` groups get the `removeAfterRestore` flag set, but that does not get put into `savedGroups` because the group already exists in `savedGroups`.
I amended the logic so that when a group is in `windows[].groups[]` and `savedGroups`, the tab group state from `savedGroups` will get `removeAfterRestore` set back to true.
Not totally sure why I could reproduce this on Windows but not on macOS. It looks like the saved groups in `defaultState.savedGroups` still have `removeAfterRestore: true` set even after the `delete group.removeAfterRestore`. I don't understand how that would happen.
Differential Revision: https://phabricator.services.mozilla.com/D246377
- 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
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
- Guard the main entry-points in SidebarController to handle the window being a popup
- Amend the test to also try the shortcut to show a sidebar in a popup window
Differential Revision: https://phabricator.services.mozilla.com/D236292
