1511077 - Add basic Web Extension support

Status: RESOLVED FIXED

(GeckoView :: Extensions, enhancement, P3)

Description

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

Lots of apps want to have a way for injecting JS and messaging the app. My view is that we should leverage Web Extensions for this instead of rolling yet another content script API. For the app messaging we could consider defining the Native Messaging API[0] for Android or add something else.

I don't think we want to require xpi either. Ideally the app will be able to register a bare/unpacked/unsigned extension that's packaged as app resources.

[0] https://wiki.mozilla.org/WebExtensions/Native_Messaging

Comment 1

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

NI for other folks to chime in here if I missed anything.

Comment 2

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

To be a little more direct: I don't think we want to support page actions and all of the UI stuff with this first effort. Just content scripts + some messaging conduit to the app.

Comment 3

[Randall Barker [:rbarker]]

For Firefox Reality, we would like to use internal WebExtensions to do CSS/JS injection into certain pages to fix compatibility issue. Additionally we would like to be able to interact with error pages and custom about: pages.

Comment 4

[David Bolter [:davidb] (NeedInfo me for attention)]

We need to scope this...

Comment 5

[Sebastian Kaspari (:sebastian; :pocmo)]

> Lots of apps want to have a way for injecting JS and messaging the app. My view is that we should leverage Web Extensions for this instead of rolling yet another content script API.

+1

> To be a little more direct: I don't think we want to support page actions and all of the UI stuff with this first effort. Just content scripts + some messaging conduit to the app.

yep!



Some random thoughts:

* It would be great if we could load and unload an extension (pre-MVP) to have the foundation for gradually adding support for web extension APIs.

* My assumption is that GV will not provide any of the "addon manager" things to an app (What extensions are installed? Download updates, ...). So I assume that is something the app will have to do and that's something we would write a component for?

* For some of the WebExtension APIs we need a channel back to the app (e.g. opening/closing tabs). That's probably another case for an Android Component where we connect this/those delegate(s) to our other components?

Comment 6

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

(In reply to Sebastian Kaspari (:sebastian) from comment #5)
> Some random thoughts:
> 
> * It would be great if we could load and unload an extension (pre-MVP) to
> have the foundation for gradually adding support for web extension APIs.

I don't think I'm parsing this right. Can you rephrase?

> 
> * My assumption is that GV will not provide any of the "addon manager"
> things to an app (What extensions are installed? Download updates, ...). So
> I assume that is something the app will have to do and that's something we
> would write a component for?

I think initially we'd only support local extensions, so all of the updating would be taken care of by the app when a new apk is installed. I guess if you want to update an extension outside of the app apk you could add some component for doing that.

Also, I think we'd want Gecko to treat these as transient or temporary -- meaning your extension registration would not be persisted. On each startup you would need to tell WebExtensionManager (or whatever) that you want to load your extension. This may be a performance issue, not sure. I think it will be the easiest way for apps to reason about whether or not an extension is loaded and active.

> 
> * For some of the WebExtension APIs we need a channel back to the app (e.g.
> opening/closing tabs). That's probably another case for an Android Component
> where we connect this/those delegate(s) to our other components?

I think we're going to punt on all of that for this first iteration. But yeah, I think you'd register delegates on WebExtensionManager to implement those things.

Comment 7

[Jan Henning [:JanH]]

(In reply to James Willcox (:snorp) ([e-mail]) from comment #6)
> Also, I think we'd want Gecko to treat these as transient or temporary --
> meaning your extension registration would not be persisted. On each startup
> you would need to tell WebExtensionManager (or whatever) that you want to
> load your extension. This may be a performance issue, not sure. I think it
> will be the easiest way for apps to reason about whether or not an extension
> is loaded and active.

1. Is that approach intended only for internal "extensions", or do you want to treat user-installed extensions (once those are supported in a later stage) the same way?
2. That means that extensions cannot use the local storage for anything that needs to persist beyond the current session, right?
3. Some extensions want to intercept network requests or other things as early as possible, could the "let the embedding app 'install' them on each startup" approach cause any problems? Although again this is probably more of a concern once we get to the stage of general (user-installed) extension support.

Comment 8

[Sebastian Kaspari (:sebastian; :pocmo)]

> I don't think I'm parsing this right. Can you rephrase?

Oh, sorry. What I meant is: Even if we do not know which WebExtensions APIs we want to support and how, but if we could define (and implement) the GeckoView APIs for loading and unloading WebExtensions from disk (even if they can't really do anything yet) then this would be very help for us already to shape the AC APIs and components.

> 2. That means that extensions cannot use the local storage for anything that needs to persist beyond the current session, right?

I haven't looked at the details of the APIs yet but maybe that is functionality the app (or more: a component) could provide to GeckoView (and the extensions) too via interfaces so that GeckoView doesn't need to care about the lifetime of the extensions?

Comment 9

[Colin Lee]

I don't have much experience with the WebExtensions APIs in Gecko, so I don't know explicitly which parts I'm requesting and which sections are not needed. I know there's some subset of the APIs which will allow us to add full-fledged content blocking (with CSS hiding and regex support) as a first party WebExtension in GeckoView-based browsers in the near future. That's what I'm aiming for initially.

I should dig into the APIs more deeply to understand them better. We'll want to create an Android Component WebExtension which efficiently provides content blocking with AdBlock Plus-style lists.

Comment 11

[[ex-Mozilla] Agi Sferro | :agi]

We have many first-party WebExtension running on GeckoView-based browsers so we can definitely resolve this.

Comment 12

[Chris Peterson [:cpeterson]]

Moving some extension bugs to the GeckoView::Extensions component.