1215306 - (webext-native.js) Full native.js support

Status: RESOLVED WONTFIX

(WebExtensions :: Untriaged, defect)

Description

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

This bug will cover all the pieces we need for native.js. That will include infrastructure for people to upload native.js modules, the way they'll be reviewed, versioning, and dependencies between normal extensions and native.js extensions.

Comment 1

[Kent James (:rkent)]

Kris pointed out to me this native.js plan. It seems to me this is a fairly significant concession to legacy gecko extension methods, and as such deserves some public discussion. Hoping to see some soon, with a reference to that in these bugs.

Comment 2

[Erik Vold]

Kent makes a good point.

How is this different than `require('chrome')` usage with the add-on sdk?  and more importantly how is this better then using `require('chrome')`?

Seems like Mozilla is spending millions of dollars to throw out the sdk's `require('chrome')` usage (the part that makes it extendable at the margins) and replace it with Google Chrome extensions (which are non-extendable walled gardens) that can do the same thing as `require('chrome')`.  Is this correct?

Also will there be more or fewer permissions than `require('chrome')` enabled? since `require('chrome')` did atleast restricted the usage of `Components` a tiny bit.

Comment 3

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Certainly require('chrome') and native.js are similar. require('chrome') led to some problems, and I'm hoping we can design something that avoids some of those problems. In my experience, require('chrome') caused stagnation in the SDK. There wasn't much pressure on Mozilla to add new APIs since people could just do it themselves with require('chrome'). And although people could use npm to share these modules, I don't get the sense that it happened much in practice. 

I think we can address those issues. Here are some of the ideas we've discussed:

- native.js code would be in its own separate extensions that wouldn't have any user-visible functionality. It would just expose an API to other extensions.
- native.js extensions would go through a more intensive review process. I would like there to be a well-defined roadmap for native.js extensions to be refined into APIs that could be integrated into Firefox.
- native.js code would have to be open source and Mozilla would have the ability to change it and push new versions of the native.js extension. In a sense, writing a native.js extension would be similar to contributing code to the Firefox frontend. The difference is that this code could be shipped to users immediately and, since the code is optional, the review bar would be lower.

I don't think there will be any technical limitations on what sort of XUL or XPCOM access is permitted from native.js. Use of native.js from other extensions will require those extensions to ask for special permissions in their manifest.

Comment 4

[Erik Vold]

(In reply to Bill McCloskey (:billm) from comment #3)
> Certainly require('chrome') and native.js are similar. require('chrome') led
> to some problems, and I'm hoping we can design something that avoids some of
> those problems. In my experience, require('chrome') caused stagnation in the
> SDK. There wasn't much pressure on Mozilla to add new APIs since people
> could just do it themselves with require('chrome'). And although people
> could use npm to share these modules, I don't get the sense that it happened
> much in practice. 

There are some holes in this logic I think, and I think it's important to get these facts right so everyone is talking about the same issue, so please let me try to take them one at a time.

> "In my experience, require('chrome') caused stagnation in the SDK."

I experienced the opposite.  `require('chrome')` not only made the sdk more useful, it also accelerated the sdk's evolution.

I was working on the sdk from the beginning, 5+ years ago, and thru it's entire lifespan up until June of this year, and this is not something that I saw, and it's not an issue that was mentioned anywhere that I recall and I had my finger on the communities pulse.  Please show me a link to prove me wrong.

> There wasn't much pressure on Mozilla to add new APIs since people could just do it themselves with require('chrome').

This doesn't ring true to me either, and I was one of the people implementing apis.  We had a lot of pressure to include new apis, and for good reason.  I think the sdk could have implemented many more apis more quickly if there wasn't so much emphasis put on how the apis were implemented.  First apis were implemented with OOP, then we were forced to use Traits, then we were forced to unimplement traits and use functional programming styles, then we were told to use MVC, and after that we had to use Signals everywhere..  This is what caused the stagnation in the sdk imo, and I was involved from the start until a few months ago.


> And although people
> could use npm to share these modules, I don't get the sense that it happened
> much in practice. 

I was only able to implement this late last year, so it has not been an option for more than a year.. 

I was only able to implement this after the SDK dissolved around me and I was the only person left working on the project, and because I was doing the work that the whole team used to do I failed to evangelize the feature effectively in such a short amount of time.

As far as i could tell however the npm usage was a pretty quickly adopted by a few extensions, like Firebug, after it was implemented, even though it was only working in nightly for awhile.

> I think we can address those issues. Here are some of the ideas we've
> discussed:
> - native.js code would be in its own separate extensions that wouldn't have
> any user-visible functionality. It would just expose an API to other
> extensions.

This seems like a redundant argument to me because we could do the same thing with `require('chrome')`.  Am I wrong?

> - native.js extensions would go through a more intensive review process. I
> would like there to be a well-defined roadmap for native.js extensions to be
> refined into APIs that could be integrated into Firefox.

Again I don't see why using `require('chrome')` can't handle this.

> - native.js code would have to be open source and Mozilla would have the
> ability to change it and push new versions of the native.js extension. In a
> sense, writing a native.js extension would be similar to contributing code
> to the Firefox frontend. The difference is that this code could be shipped
> to users immediately and, since the code is optional, the review bar would
> be lower.

Again I don't see why using `require('chrome')` can't handle this.

> I don't think there will be any technical limitations on what sort of XUL or
> XPCOM access is permitted from native.js. Use of native.js from other
> extensions will require those extensions to ask for special permissions in
> their manifest.

Again I don't see why using `require('chrome')` can't handle this.

Comment 5

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I'm sorry, I shouldn't have used such a loaded work like "stagnation". The problem I was trying to point out is that many of the SDK add-ons I've seen use require('chrome') to do the same common things like http-on-modify observers, content policies, and other nsIChannel-related stuff. They all have their own slightly different way of doing it, and it would have been better if the SDK provided an API to satisfy the most common uses.

I understand that the npm-based solution addresses the problem. And indeed I've seen a few add-ons that use the content policy module you created. The purpose of native.js is to go further and *require* that this code be split off into its own separate add-on so that it can be updated independently, possibly by Mozilla.

Splitting the code into a separate add-on creates technical challenges (like versioning, which you pointed out in a separate bug) which these bugs will address. require('chrome') doesn't solve these problems.

Comment 6

[Andy McKay]

Please see bug 1199718 comment 31.