1796183 - [meta] Add API support for event pages

Status: RESOLVED FIXED

(GeckoView :: Extensions, task, P2)

Comment 1

[Chris Peterson [:cpeterson]]

MV3 P2

Comment 2

[Arturo Mejia [:amejia]]

Rob 👋, are you aware of any specific changes to the event page APIs that we have to exposed or handled on GeckoView that are concerned to Android?

Thanks in advance!

Comment 3

[Rob Wu [:robwu]]

While the event page implementation itself is generic and not platform-specific, there are some tasks to meet the minimum bar of compatibility.

Convert ExtensionAPI to ExtensionAPIPersistent

There are only a few remaining mobile-specific extension API implementations that need to be updated to account for the possibility of being suspended:

• https://searchfox.org/mozilla-central/rev/e35e7107299a46a696b8aa8a4a5c03a39458ac21/mobile/android/components/extensions/ext-downloads.js#149
• https://searchfox.org/mozilla-central/rev/e35e7107299a46a696b8aa8a4a5c03a39458ac21/mobile/android/components/extensions/ext-tabs.js#91

Here are examples of how the desktop implementations were updated (plus unit tests):

• https://hg.mozilla.org/mozilla-central/rev/8895c48850e7123d78cf3dcd010e60490bbd5a34 (tabs API)
• https://hg.mozilla.org/mozilla-central/rev/784ea5bca99393f66217c4e5cf50e9d9acf263b6 (downloads API).
  • The new unit test here was disabled on Android because the downloads API internals differ for desktop and Android. Android's GeckoView side does have an implementation of downloads (bug 1656336), but lacks integration in A-C and/or Fenix (bug 1538348).

The conversion itself is trivial, so it could be a good exercise in running extension tests and making small changes there. The testing of the downloads API would be much more involved, but if you're experienced with GV development it should be feasible to mock the download internals (via DownloadDelegate; see patches from bug 1656336), either as a xpcshell test or a mochitest.

Devtools integration

about:debugging for add-ons on desktop features the state of the event page and the ability to suspend/wake up the event page. This was added in bug 1748529. Need to confirm that this works for mobile too.

Keep alive for Native messaging

In bug 1770696, logic was added to make sure that the event page does not shut down early when there is an open connection to a nativeMessaging application. While Firefox for Android does not support third-party nativeMessaging like desktop, it does offer the nativeMessaging API to allow (privileged) extensions to connect with GV/embedders. In these cases, the event page should also be kept alive.

Evaluate compatibility with non-persistent background scripts

An event page is like a background page, but non-persistent. The internals of GV (and consumers such as A-C/Fenix?) should be audited, to see if there is anything that assumes the extension to be alive forever. They should not assume that, because event pages codify that the background scripts of extensions can be terminates/resumed during the extension's lifetime, by design.

Comment 4

[Arturo Mejia [:amejia]]

Thanks for all the details!

Comment 5

[Rob Wu [:robwu]]

Android-specific work has mostly been completed ( https://bugzilla.mozilla.org/show_bug.cgi?id=1823436#c1 ).

There are still improvements to event pages that we can make, but that is an effort shared with the desktop implementation (bug 1748522).