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
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
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
- 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
This moves a handful of things to run slightly later, but primarily it makes
sure that the scheduling and conditions under which each bit of telemetry is
collected is clear and in one place, instead of spread around.
Differential Revision: https://phabricator.services.mozilla.com/D244421
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
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
The asserts for key length in TelemetryScalar.cpp are removed to match the previous behavior of silently ignoring these errors. The JS code path didn't have these asserts, but recording through Glean and a telemetry_mirror uses the native code path.
Differential Revision: https://phabricator.services.mozilla.com/D226686
Assumption: Browser Usage Telemetry (ideally) records only and all interesting
interactions with Firefox Desktop's UI, and preserving syntax and semantics
when instrumenting using events is valuable.
Value this provides over existing keyed scalars:
* Order of operations (did three tabs open and then three tabs close, or did
a single tab open-close three times?)
* Flow control (several atomic interactions combine to a user task. flow_id
grouping allows us to see that easily in analysis. e.g. Open a tab, open
prefs, privacy prefs, change a setting.)
* Glean
This is aiming for prototype quality and a prototype lifetime, to see if it's
worth investing more than just a week or two into.
Differential Revision: https://phabricator.services.mozilla.com/D207908
updateTrackingSinglePageApp() contains the core logic for when we observe same document loads.
Based on conditions, it may record telemetry (engagement/abandonment), and dispatch events
to the appropriate SearchSERPTelemetry actor.
SearchSERPTelemetryChild had to be modified to allow for manual dispatching of events, especially
unloading event listeners in the case where a user navigates to a non-default search page, like
Images or Shopping.
One complication in observing clicks is we're storing search pages based on the URL at the time
of load, and then looking them up again using the originURL, but it might be different from
the currentURL due to the way single page apps work. So this could cause confusion if multiple SERPs
are open and different from their originURL, hence the usage of recovering the correct state map by
first using the browser object and defaulting back to the originURL if the WeakMap doesn't
contain any of the browser objects.
I also created a mock SPA html file that when given a search query parameter, shows mock results.
The helper file head-spa.js contains a class that navigates the pages in tests.
The tests are broken out into the following:
- When a single search provider is opened in a single tab
- When a single search provider is has multiple tabs open
- When multiple providers are open at the same time
- Event listeners on in-content elements are unloaded properly when navigating away from the page
Differential Revision: https://phabricator.services.mozilla.com/D193320
updateTrackingSinglePageApp() contains the core logic for when we observe same document loads.
Based on conditions, it may record telemetry (engagement/abandonment), and dispatch events
to the appropriate SearchSERPTelemetry actor.
SearchSERPTelemetryChild had to be modified to allow for manual dispatching of events, especially
unloading event listeners in the case where a user navigates to a non-default search page, like
Images or Shopping.
One complication in observing clicks is we're storing search pages based on the URL at the time
of load, and then looking them up again using the originURL, but it might be different from
the currentURL due to the way single page apps work. So this could cause confusion if multiple SERPs
are open and different from their originURL, hence the usage of recovering the correct state map by
first using the browser object and defaulting back to the originURL if the WeakMap doesn't
contain any of the browser objects.
I also created a mock SPA html file that when given a search query parameter, shows mock results.
The helper file head-spa.js contains a class that navigates the pages in tests.
The tests are broken out into the following:
- When a single search provider is opened in a single tab
- When a single search provider is has multiple tabs open
- When multiple providers are open at the same time
- Event listeners on in-content elements are unloaded properly when navigating away from the page
Differential Revision: https://phabricator.services.mozilla.com/D193320
