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
Record when users delete an open group from the tab group context menu or delete an open group from a context menu in the all-tabs menu.
This will not record when users close a window or close all of the individual tabs in a tab group, even though those cases have the logical side effect of deleting a tab group.
Differential Revision: https://phabricator.services.mozilla.com/D241884
Now that the ReviewChecker sidebar can auto-open and close, the logic for finding distinct navigations needs to be updated.
This allow us to detect the first time new products URLs are requested to shown in the sidebar and to check if a tab should auto-open the sidebar after it was closed.
- `isDistinctProductPageVisit` now works the same as it did in the ShoppingSidebar, indicating that there was a product navigation while a tab was in the background.
- `reviewCheckerWasClosed` now prevents the sidebar from re-opening on tab changes for a location it was closed on.
- `isSimulated` is set to false in the location change handlers on tab changes where there was an unhandled background product navigation.
- Moves the `isSameProduct` check to `ShoppingUtils` and use that to test previous URIs passed to `hasLocationChanged`.
- Manager will only handle product page specific parts of location changes when the sidebar is not open to handle them.
Differential Revision: https://phabricator.services.mozilla.com/D241446
Record when users delete an open group from the tab group context menu or delete an open group from a context menu in the all-tabs menu.
This will not record when users close a window or close all of the individual tabs in a tab group, even though those cases have the logical side effect of deleting a tab group.
Differential Revision: https://phabricator.services.mozilla.com/D241884
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
This patch changes the backing prefs by relying on the tristate offered
by browser.display.document_color_use instead of
browser.display.use_system_colors. This simplifies the color
decision tree, and offers a simplified UI.
The tristate preference offered to the user is as follows:
1. "Use platform's contrast settings" (document_color_use=0)
2. "Off" - never use HCM, regardless of platform setting (document_color_use=1)
3. "On" - always use HCM, regardless of platform setting (document_color_use=2)
Option 3 also reveals a colors UI for the user to choose the palette the
browser HCM will use (bg/text/link/visited).
There are three color palettes to choose from in light of the preference
above they are:
1. WIDGET_COLORS: The OS's configured colors used by its theme.
2. HARDCODED_COLORS: Colors deemed as standard and are hard coded into
Firefox (eg. white on black text, blue and purple links).
3. PREFERENCE_COLORS: Colors that are stored in preferences and are
configurable from the colors UI (eg. browser.visited_color and
browser.display.background_color)
The decision over which palette to use is as follows:
* If we are styling browser UI -> WIDGET_COLORS
* else, if resist fingerprinting is enabled -> HARDCODED_COLORS
* else, if document_color_use==0 AND OS HCM is on -> WIDGET_COLORS
* else, if document_color_use==2 -> PREFERENCE_COLORS
* else -> HARDCODED_COLORS
Differential Revision: https://phabricator.services.mozilla.com/D211115
