1500828 - Allow privileged communication between an app using GeckoView and https://accounts.firefox.com/

Status: RESOLVED DUPLICATE of bug 1518843

(GeckoView :: General, enhancement, P3)

Description

[Ryan Kelly [:rfkelly]]

This bug continues a conversation from the Oct 17 "Mobile Tech Leads" meeting, and more context may be available in the related mailing-list thread:

  https://mail.mozilla.org/pipermail/sync-dev/2018-October/001707.html

I wanted to move it into a bug to ensure that we don't lose track of it; I've tried to focus the bug by being as narrow as possible on the "what", but as broad as possible on the "how".

--

For browser-like apps that use both GeckoView and Firefox Accounts, we need a way to allow privileged communication between the application and web-content running on https://accounts.firefox.com.

Here are two examples of how such communication is used in our current browsers, assuming the user is signed in to their browser with FxA:

* If the user visits https://accounts.firefox.com/settings and changes their account password, then the web content sends a message to the browser to tell it that its current session token was invalidated, and gives it a new one so that it can seamlessly continue syncing.

* If the user visits https://addons.mozilla.org and goes to sign in, they will be redirected to https://accounts.firefox.com.  The web content coordinates with the browser to allow the user to sign in to this website without re-entering their password, by using their existing login session from the browser itself.


On Desktop and Android, this privileged communication is done via "WebChannels", a special bit of plumbing in Firefox that ferries events back and forth between chrome and web content:

  https://dxr.mozilla.org/mozilla-central/source/toolkit/modules/WebChannel.jsm
  https://dxr.mozilla.org/mozilla-central/source/toolkit/actors/WebChannelChild.jsm

The web content on https://accounts.firefox.com basically does:

  `window.addEventListener('WebChannelMessageToContent', handler)`

to listen for messages from the browser, and:

  `window.dispatchEvent(new window.CustomEvent('WebChannelMessageToChrome', {...}))`

to send messages to the browser.  There's corresponding logic inside of Firefox to make sure that 'WebChannelMessageToChrome' events get routed to an appropriate handler function, with appropriate security checks on the page origin etc.


On Firefox for iOS, this privileged communication is done by opening https://accounts.firefox.com in a special WebView instance and injecting javascript into the page to manage the events:

  https://github.com/mozilla-mobile/firefox-ios/blob/master/Client/Frontend/Settings/FxAContentViewController.swift

This has the disadvantage of only working when https://accounts.firefox.com is loaded into this special webview (e.g. from the "account settings" menu option) but not when the user just navigates to FxA on the web.


What's the right way for us to implement this behaviour in a GeckoView app such as Fenix, or the reference-browser?

Comment 1

[Chris Peterson [:cpeterson]]

[geckoview:fenix] because Fenix will want this feature.

Comment 2

[Ryan Kelly [:rfkelly]]

:snorp, in a recent meeting you mentioned looking to a webextensions-style "content script" API to help solve this, when you've got a moment could you please share an overview of what that might look like from the consumer side of a geckoview application?

Comment 3

[James Willcox (:snorp) ([e-mail]) (he/him)]

(In reply to Ryan Kelly [:rfkelly] from comment #2)
> :snorp, in a recent meeting you mentioned looking to a webextensions-style
> "content script" API to help solve this, when you've got a moment could you
> please share an overview of what that might look like from the consumer side
> of a geckoview application?

We haven't done a whole lot of thinking in this area yet, but the gist is:

* Have a `WebExtensionManager` or similar hanging off of `GeckoRuntime`[0]. This would allow you to install, remove, enumerate, and disable/enable extensions. We'd want this to be very easy to use, so probably won't want to require signed or even packaged  extensions. Plop some stuff in your assets directory and go.

* Web Extensions have a "Native Messaging" API[1] which AFAIK is undefined on Android at the moment. We would use this to
allow communication between the app and extensions. Alternatively, we could just allow the app to listen to messages sent from the extension via `runtime.sendMessage`[2].

* `WebExtensionManager` would have methods for sending messages to extensions, as well as a delegate interface similar to the ones found in `GeckoSession` for allowing the app to listen to messages from extensions.

For this WebChannel stuff, presumably the extension could use a content script to hook into whatever it needs to do there and then use the above messaging to get the app to do stuff.

[0] https://mozilla.github.io/geckoview/javadoc/mozilla-central/org/mozilla/geckoview/GeckoRuntime.html
[1] https://wiki.mozilla.org/WebExtensions/Native_Messaging
[2] https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/runtime/sendMessage

Comment 4

[Chris Peterson [:cpeterson]]

James says this is a dupe of WebExtension bug 1518843, which Agi is already working on.