This patch fixes a number of issues that clear up a few different
intermittents in browser_tab_preview.js.
1. In browser_tab_groups_tab_interactions_telemetry.js, a call to "close
duplicate tabs" would automatically open the confirmation hint panel.
If not manually closed, it seems to persist in a half-way open state
where the `animating` attribute is always `true`. This is now fixed.
2. There is a test somewhere that seems to apply the
`sidebar.verticalTabs` pref and doesn't turn it off. I would like to
figure out which test is causing this, but as a last defence I have
made sure this is always properly set within this test suite.
3. Some tests check that THP is disabled if another panel is open. These
used to work by opening the `appMenu-popup` menu (the hamburger menu
in the top right of the browser). The problem with this approach is
that this panel (and basically every other panel) are very complex
and are prone to change. This was causing an intermittent failure
where attempting to close this panel threw an error in console that
seemed to be specifically related to this panel. I fixed this by
creating a fake minimal panel that is guaranteed to not change as
application code changes. (I borrowed this technique from
https://searchfox.org/mozilla-central/source/browser/base/content/test/popupNotifications/browser_popupNotification_queue.js).
4. There is a suite of tests that checks that THP is disabled in the
event that a drag operation is performed. The problem is that
dragging a tab by 100px sometimes detaches the tab and creates a new
window, breaking the test run. Reducing the drag amount seems to fix
this.
5. As a last line of defence, I have added a state reset function at the
start of each test to ensure that all panels are closed and that the
mouse is not hovering over the tab strip. (The latter was being done at
the end of some tests already, but this makes sure it is consistently
applied everywhere.)
Closes bug1898099, bug1905944, bug1933597.
Differential Revision: https://phabricator.services.mozilla.com/D258976
In bug 1933744 we prevented SessionStore from reopening a saved tab group into a private window. In bug 1946761 we prevented users from saving tab groups from a private window. The general design principle has been to prevent tab group information leaking between private and non-private windows.
ActionsProviderTabGroups already respected privacy through the implementation of `Tabbrowser.getAllTabGroups`, but `SessionStore.getSavedTabGroups` doesn't respect privacy. Perhaps it should. But in any case, this patch ensures that search results in private windows don't include saved tab groups.
Differential Revision: https://phabricator.services.mozilla.com/D248351
Record when a user ungroups the tabs of a tab group.
We ungroup an entire group when the user selects the "Ungroup tabs" context menu item on the tab group, but we also do that if the user cancels out of tab group creation context menu. We are particularly interested in understanding when users cancel out of the creation process. This may give us a better indicator about accidental tab group creation, e.g. when the user intended to drag and drop to move a tab but ended up creating a tab group from two tabs.
Differential Revision: https://phabricator.services.mozilla.com/D247633
Session restore code doesn't use the standard Tabbrowser.addTabGroup API, so tab groups that enter the DOM via session restore don't raise any TabGroupCreate events. To be consistent, and in order to support addons that need to have an up-to-date view of the tab strip, this patch fires TabGroupCreate on each tab group that enters the DOM.
This patch renames the existing `TabGroupCreate` fired from Tabbrowser.addTabGroup to `TabGroupCreateByUser`. This new event will fire after the tab group enters the DOM (therefore after `TabGroupCreate`) in scenarios where code calls Tabbrowser.addTabGroup with `isUserTriggered = true` to indicate that a user took an explicit action to create this tab group as a new tab group.
Differential Revision: https://phabricator.services.mozilla.com/D246630
We are still using the nearest neighbor approach as default. This method will be tested along with Kmeans via Nimbus.
From preliminary perf. testing, it's also more performant.
Differential Revision: https://phabricator.services.mozilla.com/D246551
We were initializing two SmartTabGroupingManager instances in tabbrowser and tabgroup-menu. This was
causing issues with telemetry. This is now cleaned up.
Also, adding the model reason for no suggestion per DS request.
Differential Revision: https://phabricator.services.mozilla.com/D246113
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
For the first and last tab in a tab group, include the tab group's name in the accessibility description read by screen readers when the tab is in focus. As keyboard users go through the tab strip, the users will receive clues that they are passing into/out of a tab group.
This also reformats the tab tooltips in general.
Before:
```
$title $pid $active - $containerName
$audioPlaying
```
After:
```
$title
$pid $active
$tabGroupName - $containerName
$audioPlaying
```
For each portion of the tab tooltip string, parts of the string might not appear due to configuration (PIDs and active only shown with pref) or user state (container name only shown for a container tab, etc.) or UX choices (don't include the title in the accessibility description because screen readers already read out a tab's title by default)
Differential Revision: https://phabricator.services.mozilla.com/D245186
If a DOM rebuild was scheduled on a previous frame but the rebuild is no longer needed (e.g. due to the "list all tabs" menu no longer being open) then do not clean up nor populate the DOM.
In bug 1953533 we debounced and delayed full DOM rebuilds of the "list all tabs" menu due to severe performance impacts during event-heavy operations like restoring an entire browser session.
When the "list all tabs" menu is closed, it's supposed to get emptied and stop responding to events. However, it was possible to perform actions in the "list all tabs" menu that would trigger events and close the menu at the same time. The triggered event would schedule a "list all tabs" menu rebuild on the next frame, which would then build the "list all tabs" menu DOM despite the menu being closed. When the menu was reopened, the menu builds the menu DOM by inserting new DOM elements, but since the menu was already built, you end up with a doubled version of the tab strip.
Differential Revision: https://phabricator.services.mozilla.com/D246047
This patch adds the most basic tab interaction metrics for tab groups.
As discussed in standup, we agreed to move the `remove_` class of
metrics into its own bug due to extra complexity involved in correctly
capturing these events.
One other thing we discussed was what the scope of events should be for
the `close_` class of events, i.e. should we *only* capture an event
when someone clicks the "X" button or closes from the TOM menu, or
should we also account for things like context menus, keyboard
shortcuts, etc.? Originally we agreed to capture _all_ tab close events
and mark any source that was not one of the above mentioned two as
unknown. However, after thinking about this more, I don't believe this
is the right approach. There are many places in the codebase where a tab
is closed but not because a user deliberately did it (e.g. when moving a
tab to a new window — this is actually done by creating a new tab in a
new window and closing the old). We currently don't distinguish between
user-initiated close actions, so it would take some time to find all
these places and exclude them.
I favour an explicit inclusion approach (which is what we are doing
elsewhere). In this patch I added events for:
- closing a tab from the "X" close button (`close_tabstrip`)
- closing a tab from the tab context menu (`close_tabstrip`)
- closing a tab from the TOM (`close_tabmenu`)
There are other places that could potentially be
addressed, so I suggest moving these to a follow-up bug and addressing
them for 139.
Differential Revision: https://phabricator.services.mozilla.com/D244915
Set aria-setsize on grouped tabs to the number of tabs in the tab group. Set aria-posinset on grouped tabs to the 1-based index of the tab within the tab group. This allows some a11y tools to report to the user that a tab is, for example, tab "2 of 7" in a tab group.
The tab strip uses the `tablist` ARIA role. The ARIA spec and Firefox's a11y engine both forbid nesting `group` ARIA roles inside of `tablist`. As a result, a11y tools always read individual tabs as being tab "X of Y", where Y is the number of tabs in the tab strip and X is the index of the tab in the tab strip. This is good information, but it does not give the user a sense of where a tab is within a tab group.
Differential Revision: https://phabricator.services.mozilla.com/D245185
Tabs outside of tab groups are at the top level (level 1) while tabs inside of tab groups are at the next lower level (level 2). This helps unsighted users get a better sense about the hierarchy of the tab strip.
Differential Revision: https://phabricator.services.mozilla.com/D245184
Tabs outside of tab groups are at the top level (level 1) while tabs inside of tab groups are at the next lower level (level 2). This helps unsighted users get a better sense about the hierarchy of the tab strip.
Differential Revision: https://phabricator.services.mozilla.com/D245184
- 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
