On Sat, 20 Oct 2018 at 04:34, Nicholas Alexander <[email protected]> wrote: On Fri, Oct 19, 2018 at 7:43 AM Stefan Arentz <[email protected]> wrote:
> > > >> >> 1. >> 2. WebChannels >> >> <https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules/WebChannel.jsm> >> in GeckoView-consuming browser-like Apps. WebChannels are a >> Firefox-specific chome-only feature that allows the browser chrome to >> communicate via message-passing with trusted Web Content; they are used to >> integrate Firefox with accounts.firefox.com and addons.mozilla.org. >> We need something that provides this functionality in the Reference >> Browser >> to support a first-class Firefox Accounts experience. Privileged Web >> Extensions are ideologically pure but don't have a concrete date on the >> GeckoView roadmap. Suggestions gratefully accepted! >> >> > Can we learn anything from how this was implemented on iOS? If I remember > correctly, we inject a helper user script into the webview, which then sets > up the right glue to do messages between the native application and the FxA > page loaded in the webview. > This is a good point, because IIRC Firefox for iOS doesn't actually support WebChannel messages in the same way that Desktop and Android do. On Desktop and Android, any tab that loads web content from https://accounts.firefox.com gets some special message listeners hooked up, and the web content can send privileged messages to the browser. This is why, for example, you can just browse to this page on Desktop, punch in your account credentials, and get your browser connected to Sync: https://www.mozilla.org/en-US/firefox/accounts/ On Firefox for iOS, the message listeners get hooked up when viewing https://accounts.firefox.com in a special webview through the "settings" menu, but they won't get hooked up if you just open a tab and browse to https://accounts.firefox.com on the web. (That's my recollection anyway; if I'm wrong please correct me!) One note, and please correct me if I am wrong: but the web based FxA login > flow can not depend on GeckoView - it has to work in both the system > webview and geckoview. It is not practical for non-browser applications to > pull in a giant dependency on GeckoView if all they need is a place to show > a web based login flow. Whatever we do here needs to work in both the > system webview and geckoview. > This is 100% correct. The use of this special message-passing stuff is for a very specific use-case - browser-like apps that want to be able to host account management UI by opening up https://accounts.firefox.com. Non-browser applications will only want the existing OAuth signin flow, not all the extra account-management stuff, so should work fine with either GeckoView or the system browser. Cheers, Ryan
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
