880908 - Change SDK API code or create official adapters to inter-operate with non-privileged code

Status: RESOLVED INCOMPLETE

(Add-on SDK Graveyard :: General, enhancement)

Description

[Brett Zamir]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0 (Beta/Release)
Build ID: 20130511120803

Steps to reproduce:

I made an add-on for Firefox and then realized much of the code ought to be reusable within a regular, though less full featured, web application (e.g., with default cross-domain restrictions in the web app). Ideally, my Firefox and web app code would be the same, but with modules suitable to the environment.


Actual results:

Even while I know there is require.js, I feel I am spending unnecessary effort (not to mention potential instability if the adapters will not be officially maintained) to make my own adapters if such code could be provided and maintained officially. I'd also like to see the non-Firefox-specific functionality and APIs of the SDK leverageable out-of-the-box as much as possible by web app code, while safely ignoring Firefox-specific features (without my needing to hack the SDK source code each time to do so).


Expected results:

(As with bug 855936, I am interested here also in seeing the increased use of CommonJS-style JavaScript reach more of its potential in providing greater interoperability of code and APIs across environments.)

In the case described above, I would like to have been able to find a Firefox-supported web app drop-in script, so that I could reuse my add-on/content script code in my web app, and when my "add-on" code creates a web app Panel module, this module could, upon instantiation, create a global "self" object and allow calls to "on" or "emit" to be passed between either object (so that it will inter-operate with my "content script" which should at a minimum continue to work since it has no other privileges from regular web app code anyways).

The "add-on" code could in turn require modules following in some cases a different implementation from the SDK implementation, but coordinated with it as far as possible (including if the browser ends up supporting functionality that was not possible today). (I'm also holding out hope that if the web app wanted to use the modules to ask the user for permission to run privileged code, the API might also support such requests such as I have attempted to do through https://github.com/brettz9/asyouwish/ .)

In web app code, there would therefore not be any different scope between the "add-on" code and the "content" script, but one's web app code would still be reusable as real add-on code (just swapping module implementations on the browser side where different functionality was needed).

An added benefit is that my web app would most likely end up providing clean, abstract bridges separating DOM logic from other business logic. Such a swappable framework might also facilitate cross-browser extension development as well.

Comment 1

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

Brett can you be little more specific in ragards to what changes you want on SDK side ? We all wish to increase interoperability between different platforms that run JS and I believe we're getting there one step at a time. This request seems to be very generic and maybe deserves project of it's own or maybe I just fail to understand what changes you have in mind for SDK that would allow that.

Comment 2

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

Brett, I'd also suggest maybe writing up a JEP like others we written https://github.com/mozilla/addon-sdk/wiki/JEP for a changes that have a bigger scope than a bug fix.

Comment 3

[Brett Zamir]

Sorry for the delay in replying. I hope to provide some sample code a little bit down the road which shows the idea after getting through a current project.

Comment 4

[Dave Townsend [:mossop]]

Right now this shows up in our triage list every week but without more information we don't have a lot to do with it. For now I'm going to close this bug. Brett feel free to reopen or open a new bug when you have more information to share.