1938424 - Record telemetry event when adding tabs to a tab group

Status: RESOLVED FIXED

(Firefox :: Tabbed Browser, task, P2)

Description

[Stephen Thompson [:sthompson]]

Event category: tabgroup
Event name: add_tab
Description: Recorded when the user adds a tab to a tab group
Extras:

• source (string): "tab_menu" | "drag"
• tabs (quantity): total number of tabs added to the tab group in this operation
• layout (string): "horizontal" | "vertical"

This event should be recorded when the user takes an explicit action to add tabs to an existing tab group. This event should not be recorded when creating a new tab group from some number of tabs; that should already be accounted for in bug 1938423.

Comment 1

[Stephen Thompson [:sthompson]]

Attachment: Bug 1938424 - metrics event when tabs added to tab group r=dao,dwalker,jswinarton

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.

In order to keep the telemetry logic contained in BrowserUsageTelemetry, I introduced a few new events for the browser code to fire:

• MovingTabsToTabGroup when using the tab context menu to add tab(s) to a tab group
• TabsDropped when drag-drop moves or duplicates tabs to a new location in the tab strip
• TabMoved when a tab has logically changed position in the tab strip or changed its tab group membership

There is an existing TabMove event derived from UIEvent being fired when tabs change their tab index in the tab strip, but UIEvent doesn't allow for attaching additional context/detail to the event. The new TabMoved 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. One alternative would be to record metric data at each site in the code where tabs can move, but I believe that would require spreading out this metric logic across many methods.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/21f1ad4b5bf3
metrics event when tabs added to tab group r=dao,jswinarton,tabbrowser-reviewers,extension-reviewers,robwu

Comment 3

[Stephen Thompson [:sthompson]]

Attachment: Bug 1938424 - metrics event when tabs added to tab group r=dao,dwalker,jswinarton

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.

Original Revision: https://phabricator.services.mozilla.com/D244616

Comment 4

[Phabricator Automation]

beta Uplift Approval Request

• User impact if declined: No immediate user impact. If this metrics event is not in 138, then we will lack awareness of how often and how much users are interacting with tab groups
• Code covered by automated testing: yes
• Fix verified in Nightly: no
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: Drag and drop ungrouped tabs into an existing tab group or select multiple tabs, right click, and choose to add to an existing tab group. There should be a single metrics event fired. The number of tabs reported by the event should match the number of tabs that moved into the tab group.
• Risk associated with taking this patch: Low/Medium
• Explanation of risk level: Generally low risk since most code is reacting to events in order to record metrics. Failures in that code shouldn't affect users. There may be slightly more risk because this patch also includes a JS module move/rename that touched a number of files.
• String changes made/needed: No
• Is Android affected?: no

Comment 5

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/21f1ad4b5bf3

Comment 6

[Dianna Smith [:diannaS]]

Comment on attachment 9478652 [details]
Bug 1938424 - metrics event when tabs added to tab group r=dao,dwalker,jswinarton

Approved for 138.0b8

Comment 7

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/202c4660431b

Comment 8

[Jeremy Swinarton]

Attachment: Bug 1938424 - metrics event when tabs added to tab group r=dao,dwalker,jswinarton

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.

Original Revision: https://phabricator.services.mozilla.com/D244616