1864161 - Record ExtensionTelemetry browserActionPopupOpen and pageActionPopupOpen glean metrics from GeckoView builds

Status: RESOLVED WONTFIX

(WebExtensions :: Android, task, P2)

Description

[Luca Greco [:rpl] [:luca] [:lgreco]]

As part of Bug 1820158 we are porting our unified telemetry histograms related to the WebExtensions internals to Glean metrics, which will allow most of those metrics to be collected from GeckoView-based browsers (in particular Firefox for Android) right away, besides ExtensionTelemetry.browserActionPopupOpen and ExtensionTelemetry.pageActionPopupOpen which are both being collected from browser-level internals and not being currently collected by the corresponding WebExtensions API implementation that is used in GeckoView builds:

• https://searchfox.org/mozilla-central/search?q=browserActionPopupOpen.&path=&case=false&regexp=false
• https://searchfox.org/mozilla-central/search?q=pageActionPopupOpen.&path=&case=false&regexp=false

This bugzilla issue is tracking following up to introduce the additional changes needed (on top of the ones introduced by Bug 1820158 to introduce general Glean support in ExtensionTelemetry.sys.mjs) to start calling ExtensionTelemetry.browserActionPopupOpen and ExtensionTelemetry.pageActionPopupOpen also from the GeckoView implementation of the browserAction/pageAction WebExtensions APIs.

Comment 1

[Luca Greco [:rpl] [:luca] [:lgreco]]

Yesterday I took a more closed look into how these two probes are recorded on desktop, and into the differences between the browserAction/pageAction popups as being handled on Desktop vs Android builds to determine:

• how and where in the code base these metrics could have be collected
• if "what these metrics represents on Firefox Desktop" would also apply to Android builds

Based on this closer look, we have determined that:

• the metrics as we are collecting on Desktop builds and the ones we could collect on Android builds would be measuring different things, and so they wouldn't be directly comparable with each other and so using the same metric name would be very likely more confusing than helpful
• the questions that these metrics are meant to answer on Desktop builds do not actually apply to Android builds, and so adding these probes should be deferred to when we got actual questions that applies to Android builds that new browserAction/pageAction metrics would help to answer (and a new bugzilla issue to be filed to track those new questions and adding new probes to answer them), and this bugzilla issue to be closed as wontfix.

Follows some more details about what these two metrics are measuring on desktop and why they don't apply to mobile builds.

---

What are these metrics measuring on desktop builds

ExtensionTelemetry.browserActionPopupOpen

In Firefox Desktop builds, the browserAction popups are being preloaded while still invisible (the html page gets loaded, but the scripts included in it blocked) when the users are hovering the browserAction toolbar button with the mouse, and then the preloaded extension page may be destroyed if the user move the mouse outside of the browserAction toolbar button, or made it visible and the page scripts unblocked if the user actually clicks on the button.

This metrics is measuring the time passing between the popupshowing event and the invisible preloaded browser element being fully swapped with the empty browser element part of the popup panel being shown, see:

• ViewPopup attach method: https://searchfox.org/mozilla-central/rev/7e60ac48dc5b3e3f06c1baf2a9a6e0352bd85c01/browser/components/extensions/ExtensionPopups.sys.mjs#575-705
• browserAction onViewShowing method: https://searchfox.org/mozilla-central/rev/7e60ac48dc5b3e3f06c1baf2a9a6e0352bd85c01/browser/components/extensions/parent/ext-browserAction.js#391-444

differences in the way this works on Android builds

• we don't have the same preloading mechanism (nor the concept of hovering with a mouse given that the primary interaction is happening through touch)
• the opening and triggering of the popup pages to be loaded is mainly handled on the GeckoView side (see the WebExtension.Action click and openPopup method, GeckoSession.load method and the code in GeckoViewWebExtension.sys.mjs "GeckoView:LoadUri" geckoview message handlere here) and the Android specific ext-browserAction.js internal returning a popup url from the method BrowserAction.triggerClickOrPopup (called from GeckoViewWebExtension.sys.mjs "GeckoView:BrowserAction:Click" GeckoView message handler here)

and so the measure we could collecting on mobile would not be the same as the one in desktop, and the questions we were meant to answer with the desktop metric (related to the preloading mechanisms) don't apply to the mobile browserAction.

ExtensionTelemetry.pageActionPopupOpen

In Firefox Desktop builds, the pageAction popups do not have the same preload mechanisms that browserAction popups have, but unlike the popups UI we use in Firefox for Android, the pageAction popups may have to be resized based on the styles and scripts running, and the ExtensionTelemetry.pageActionPopupOpen metric is collecting the amount of time passed between handling the user clicks on the page action button and the DOMContentLoaded event being emitted for the the popup page and have computed the document size once after that (see ext-pageAction.handleClick method here and the code emitting the BrowserListener.handleDOMChange method defined in ext-browser-content.js here).

differences in the way this works on Android builds

On mobile the code handling the pageAction popup is basically the same as the one mentioned for the browserAction.

The code loading the popup (GeckoViewWebExtension.sys.mjs "GeckoView:LoadUri" geckoview message handlere here) does know that is loading a popup but it doesn't know if it is a browser or page action popup.