How is one supposed to develop mobile add-ons with a UI?

Add-ons Development
#1

Mobile support seems to be rather limited in both the Add-on SDK and WebExtensions - the way I read it not a single API to integrate your extension into the browser UI is supported. Add-on SDK at least supports opening new tabs even though it’s not clear how one would trigger this action, Web Extensions don’t even support that. So, what are the options when a mobile add-on needs the user to trigger some actions?

  • Write a classic bootstrapped add-on: bad idea, these are deprecated and will stop working eventually.
  • Use Add-on SDK and user require("chrome") in order to implement a page action: not really future-proof either.
  • Inject add-on UI into all webpages: very bad idea, opens the extension to all kinds of clickjacking and spoofing attacks.

Anything I am missing?

@andym

#2

Since we’re investing on WebExtensions as the future of add-ons, that’s where we should focus our efforts. So, a couple of questions I would pose:

  • Which existing WebExtensions APIs need Android support?
  • Which new APIs would you add for Android?
#3

I take it that I’m correct and there is currently no future-proof way?

For EasyPasswords I would need something like browserAction (with popup) and tabs (open, query and executeScript) APIs. It seems that there is only a bug open for pageAction (bug 1263005) which is inconvenient for an action that should be always present. Still, it would be sufficient but according to my tests this API appears to be unusable right now (bug filed). I also noticed that extension options aren’t working on Android (bug 1300808).

I think that the UI integration of Adblock Plus on Android is currently limited to the same elements (it’s very rudimentary). Of course, more integration points would be better - context menu support for example. And I wonder whether some kind of Developer Tools integration is possible for remote debugging of extension data.

#4

I think that should work very similar to how it works on desktop, given the debugger runs over the same protocol, so all that needs to be done is to have the same debugging entry points. This would also allow convenient remote-installation of extensions if Android also implements the action to install a temporary extension.

#5

I don’t actually think that it is simple. How this works on desktop is: the extension installs a Developer Tools panel and writes out some of its data to it. The trouble when debugging remotely is: the desktop debugger might not have the same extension installed, so even if the data is coming in the Developer Tools panel to display it just isn’t there or might be incompatible.