1826244 - Convert Firefox Accounts WebChannel ([e-mail]) extension to event pages

Status: RESOLVED WORKSFORME

(Fenix :: Accounts and Sync, task, P2)

Description

[Chris Peterson [:cpeterson]]

The Firefox Accounts WebChannel ([e-mail]) extension must be updated to use event pages because it currently uses persistent background pages or scripts, which will be incompatible with the extension process.

How to convert an extension using a persistent background script to event pages:

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Background_scripts#convert_to_non-persistent

The background script uses native messaging, see: Bug 1823432 - Keep event pages alive for Native Messaging on Android.

Comment 1

[Mark Hammond [:markh] [:mhammond]]

Note that we'd like the new event pages mechanism to be alive all the time rather than only alive for a limited lifetime like happens now with the webchannel extension, so that we are alive whenever the user visits accounts.firefox.com, even when typed manually in the address bar. Not clear if that will make this bug easier or whether it will need to be done in a followup.

Comment 2

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

Hey Mark, I took a look to the [e-mail] extension's background page and (unless I'm misreading it) it looks like its background page is only listening for an event of type “overrideFxAServer” originated from the embedder app, the listener in the background page then register a content script (the same registered from the manifest file on some Firefox Accounts related domains) and closes the port (which seems to suggest that is only used once).

The event type name of the event seems to suggest it may be only used during testing to override the Firefox Accounts server, but I wanted to explicitly confirm with you if that is the case as it seems.

Would you mind to confirm if what I'm describing is correct?

---

As some additional side notes:

• The nativeMessaging API is then also used directly from the content script to communicate with the GeckoView app, but that communication channel is directly going from the content process to the GeckoView application without involving the background page nor the extension process, and so the fxa content script would still working as expected even if the background page is gone (e.g. after an extension process crash).

• The only content script that is going to not be registered anymore if the background page is gone is the one registered in response to the "overrideFxAServer", that single dynamically registered content script would be removed automatically when the fxa background page is closed (e.g. after an extension process crash), while the one registered from the manifest will stay registered and will continue to work even while the background page and the extension child process may not be around anymore.

Comment 3

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

I took a more closer look and tried to explicitly verify that the behavior of the Firefox Accounts sign in flow is going to still be working as expected even if the [e-mail] builtin extension background page is destroyed and not recreated after an extension child process shutdown/crash using the following STR:

• Open Fenix Settings and enable USB Remote Debugging
• Open a tab on about:config
• Change extensions.webextensions.remote to be set to true
• Restart Fenix
• Open a new tab on about:processes and confirm the Extension process is running
• Open a new tab on about:crashextensions
• Switch back to the about:processes tab and confirm the Extension process is NOT running anymore
• Open the app menu and click on “Sync on save data”
• Click “use email instead”
  • Expected: Firefox accounts email based logic page loaded
• Continue the Firefox Account sign in flow
  • Expected: Firefox Account sign in completed successfully

Even when the extension process and the [e-mail] background page was not around anymore, it seems that Firefox Accounts sign-in flow was completed successfully, which is actually what we would expect based on the following details we noticed while looking more closely to the following internals:

• Based on FxaServer.kt it seems we would be selecting a FxA server override based on the built, and usually choose based the official server or the mozilla online one
• By comparing Config.kt with the matches of the content scripts registered from the [e-mail] manifest.json file we noticed that besides an arbitrary custom FxA Server url and the localhost one, all other domains in the Config.kt are already listed as matches of the content script registered from the manifest.

The content scripts registered through the manifest.json file are expected to stay registered and be injected into the webpages matching those urls even when the extension background page isn't running and so we expected the Firefox Accounts sign-in flow to still work because of that and that seems to be the case.

As a counter-proof I've tried to do the opposite: In a local build I changed all the matches in the [e-mail] manifest file template (See android-components/components/feature/accounts/src/main/assets/extensions/fxawebchannel/manifest.template.json) to never match (either removing the one for the production Firefox Accounts server or changing it to never match) and using the STR described above I verified that I was not able to complete the Firefox Accounts sign in flow successfully (the panel where the Firefox Accounts page is being loaded keeps spinning forever after clicking the “use email instead” button).

I'm clearing the needinfo and closing this issue as resolved, but let us know if there is some other STR that would show some user-related scenario where the Firefox Accounts sign-in flow would be impacted if the builtin extension background page isn't handling the overrideFxAServer event and we will consider re-opening this issue and look more closely into that.

Comment 4

[jackyzy823]

Here's a driven-by comment:

overrideFxAServer is not used for testing, It is used for allowing users to use self-hosted FxA Stack.

The origin PR https://github.com/mozilla-mobile/android-components/pull/9827

Comment 5

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

(In reply to jackyzy823 from comment #4)

Here's a driven-by comment:

overrideFxAServer is not used for testing, It is used for allowing users to use self-hosted FxA Stack.

The origin PR https://github.com/mozilla-mobile/android-components/pull/9827

I see, then porting the background page from the contentScripts.register API method to the scripting.registerContentScript one may improve the resiliency of that part to an extension process crash, the content scripts registered using the scripting API namespace (introduced in Gecko 102) are not unregistered automatically when the extension page that has registered them is closed and so the content script that creates the FxA WebChannel for the custom url related to the self-hosted FxA Stack would stay registered if it was registered before a process crash.

I'd like to double-check that when a custom URL is going to be used, the overrideFxAServer event is going to be sent early enough for that to be the case, would you mind helping me to determine an STR I could use to manually verify the expected behavior and look into that tweak to the [e-mail] background page?

Comment 6

[jackyzy823]

Hello, I'm not sure how to make a STR.

But when without passing overrideFxAServer to register content script on the self-hosted server url , Even users set self-hosted fxa server via "Secret Menu" -> "Sync Debug" , they still can not login into FxA, because the login page will showing a infinite loop icon when loading due toWebChannel messages can't get through

Reference: https://github.com/mozilla-mobile/android-components/issues/6225

---

I'm not familiar with event page related things. However background script will only run once when Fenix startup ( Changing fxa server url will cause Fenix auto-restarting itself). , may be it's safe to convert to event page? .

Comment 7

[Mark Hammond [:markh] [:mhammond]]

I don't know how this addon does the custom server magic, but I'm fairly sure the process kicks off by following https://github.com/mozilla-mobile/firefox-android/blob/main/fenix/docs/Secret-settings-debug-menu-instructions.md, which then will show a "Sync Debug" option on the main menu, where you can specify a custom FxA server. I think that if you enter "https://accounts.stage.mozaws.net/" (see https://wiki.mozilla.org/TestEngineering/Services/FxATestEnvironments#FxA_Stage_Environment) you should end up using the stage server (so you will not be able to use any existing accounts but instead will need to create a new test one). You should be able to leave the custom sync server blank. Ping me in slack if you have issues (although I've not done this for a very long time)