848647 - Gaia Web Browser Addon system - supporting/expanding/streamlining relevant Addon SDK APIs and certified-level access to all Web APIs

Status: RESOLVED DUPLICATE of bug 1180672

(Firefox OS Graveyard :: Gaia::Browser, defect)

Description

[Brett Zamir]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0
Build ID: 20130215130331




Expected results:

I would like to see an Addon system added to the Firefox OS "Web Browser" app (and if there are already such plans, I didn't see them at https://wiki.mozilla.org/Gaia/Browser or in https://github.com/mozilla-b2g/gaia/blob/master/apps/browser/js/browser.js ). (My apologies in advance if I have covered ground here already kindly addressed to me in discussions elsewhere.)

Besides the basic mechanisms of such an add-on system (sites being able to request installation, having a dialog to list installed addons, etc.), I would envision:

1. Adding support in Firefox OS Web Browser for relevant existing Addon SDK APIs (e.g., to attach page mods) and where necessary, expanding or streamlining the SDK APIs to better support the mobile environment (and desktop) as pertains to site-independent Web Browser functionality (e.g., to theme it or listen for certain touch events to active new dialogs such as a context menu), including with site-independent System app overlay capabilities as well (e.g., adding an API for modifying the system app or gaining access to a list of existing apps, etc.).

If other browser vendors are willing, standardize on such extensibility mechanisms (and ideally harmonize with, or even allow addons (including Firefox desktop ones) to become replaced by web-based privileged apps, ala https://github.com/brettz9/asyouwish/ whereby a website, without needing file packaging, can register itself as a privileged addon, or merely run with privileges on a session basis (as had enablePrivilege).

2. Harmonizing or substituting SDK APIs with Web APIs where functionality is comprehensive in Web APIs (but with certified-level access for the proposed Firefox OS addons and for desktop Firefox, granting access to all Web APIs, at least in simulated form and with graceful failures to avoid an unnecessary fracture into mobile and non-mobile HTML). Developers don't like having to write apps twice for different browsers, nor we do we like it for writing extensions or for mobile/non-mobile.

3. Merge the AMO site and Marketplace, so privileged site-independent add-ons (including mobile ones) can be marketed, and conversely, so that regular websites can be easily bundled but with the capability to ask the user for add-on privileges.

While no doubt any of these steps would take time to implement, I believe the earlier such work can begin, the earlier Firefox can see its own ecosystem explode in utility to users (as it did by providing an add-on mechanism in desktop Firefox), and the less core development that will need to take place (as add-ons can release some pent-up demand for missing functionality, the core can avoid bloat, etc.).

Comment 1

[Ben Francis [:benfrancis]]

I'm struggling to imagine how this could be made to work in a web standards based way within the security model we have defined.

Perhaps Jonas has a better imagination than me?

Comment 2

[Brad Lassey [:blassey] (use needinfo?)]

Jonas, what do you want to do here

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Creating a standardized addon system for browsers that works across different Firefox implementations (desktop/android/FFOS) or even across different browsers, is a cool idea.

However I don't think it's useful to debate it in a bug.

I'd encourage anyone that is interested in doing this to come up with a draft proposal for what such an API would look like. Preferably by looking at existing APIs like Jetpack and the Chrome addon APIs.

I think it would certainly be possible to do, but it'd likely be pretty limited in what types of addons you would be able to support. That said, it might still include some quite interesting types.

Comment 6

[ffos-browser]

A Pivotal Tracker story has been created for this Bug: http://www.pivotaltracker.com/story/show/53550081

Comment 7

[Jerzy]

How about providing built-in support for user scripts instead? http://userscripts.
User scripts are just JavaScript files which enhance the browsing experience, using Greasemonkey API: http://wiki.greasespot.net/Greasemonkey_Manual:API

Chrome supports them out of the box.

Comment 8

[Brett Zamir]

As I have used it and understand it anyways, Greasemonkey is for modifying individual websites. This is a welcome first step (and perhaps could be a starting point), but I am hopeful to see individual websites have the ability to do more than Greasemonkey such as:

1. access--upon user permission of course--ANY privileged API available to extensions including those not currently exposed to user scripts, such as say modifying the global context menu (and I hope mobile will be able to do this)
2. have the option to be remembered by the browser to outlast a given session 

In other words, for websites to be able to work like full-blown addons (or as I'm trying to do with AsYouWish).

I have replied to clarify that Greasemonkey as it is does not cover my full range of use cases, but perhaps in the spirit of Jonas' suggestion, user scripts could be considered for the approach of a cross-browser API in addition to the FF SDK and Chrome's as he mentioned (along with, I hope, Node.js' API as per Bug 855936).

I'd also hope the chosen API would at the very least not put unnecessary hurdles toward reusing the same code for less privileged development (bug 880908 which I also need to explicate better at some point), though ideally, imo, privileged code would only differ from unprivileged code in the degree of privileges agreed to by the user (including the privilege to execute upon restart in a hidden window as regular add-ons effectively do).

Btw, off topic somewhat, but FYI, http://www.zdnet.com/ubuntu-edge-might-just-change-the-computing-world-7000018464 reported on a mobile approach to harmonize with desktop (Ubuntu).

It would be cool, imo, if Firefox OS made the browser the central app, with apps being merely pinned tabs or local files and the app browser could then simply be a view of a special protocol like (file:// or app://)--an entry point into the browser viewing the pinned tabs or local web app file directory, but where the URL bar could be hidden by default, e.g., with an automatic full-screen view that has the same effect as seeing the "OS" desktop. In such a case, it wouldn't be a stretch to give privileged browser APIs the ability to modify the OS browser as well as the web browser.

I think the latter would also harmonize better with the desktop approach as one could then get the benefit of folders, and there wouldn't be two main applications in mobile and just one on the desktop (which either makes harmonization difficult or forces one to add features which only benefit say the mobile platform).

The desktop is where we all work, so I think it is a pity that has been SOOOO under-explored as far as core and extension development (despite there being one extension at one point). (Btw, I still think one could also come far closer to replacing the OS' own local desktop interface with access to local search capabilities if bug 878626 were implemented).

I am working to implement what I think could really become a killer desktop app (which would have been nice had there been a harmonized desktop-mobile API), but I have started implementing it now in AsYouWish to preserve the vanilla HTML + user-requested privileges approach I think makes sense for app development) to hopefully demo why I think this general approach is so much better and cooler for development than the add-on packaging model (though if anyone could point me to the part of the Firefox codebase responsible for file-browsing views in Firefox, I might be tempted to get it working there as well: [e-mail] ). I might add that sharing the same API as Node.js (again, as per Bug 855936) would allow the same desktop app codebase to be reused for server-side file browsing as well.

Anyways, my apologies for the long reply, and sorry for not having gotten to the hard work of making a proposal on the APIs, but I really feel something needs to be done first to demonstrate clearly the appeal of abolishing the privileged class of citizen called the "addon" and reworking the browser to invite all plebeian web apps to this level. Since I have not succeeded in assuaging the reticence to even be able to get my AsYouWish add-on hosted on AMO, I am holding out hope that demonstrating the coolness of what it can do may change some minds on the general approach.

Comment 9

[Brett Zamir]

(In reply to Jonas Sicking (:sicking) from comment #3)
> Creating a standardized addon system for browsers that works across
> different Firefox implementations (desktop/android/FFOS) or even across
> different browsers, is a cool idea.
> 
> However I don't think it's useful to debate it in a bug.
> 
> I'd encourage anyone that is interested in doing this to come up with a
> draft proposal for what such an API would look like. Preferably by looking
> at existing APIs like Jetpack and the Chrome addon APIs.
> 
> I think it would certainly be possible to do, but it'd likely be pretty
> limited in what types of addons you would be able to support. That said, it
> might still include some quite interesting types.

Would it be helpful to have a proposal looking at just one type of API for starters (e.g., URL parsing or the file system), but taking into account FF desktop and mobile, Chrome, Node, etc.? If this is ok and in case there is ongoing work drafted somewhere (as I recall, you were working on something for URL parsing yourself), could I be pointed in the direction of such documents? No promises here, just would like to know if this would be an open avenue if I can find the time...

Comment 10

[Michael Henretty [:mikehenrty][:mhenretty]]

We now support add-ons which follow the webextension format on Firefox OS. That, and the bug 1229771 should meet the needs of the origin report. If it does not, please add specific needs as a blocking bug of bug 1229771.