6 ms·

Well, XUL-based extensions are not scraped yet. They will, at some point in 2017, but we're not there yet. The reason to scrape them is simple: the total API s

by Yoric 10y ago

Well, XUL-based extensions are not scraped yet. They will, at some point in 2017, but we're not there yet. The reason to scrape them is simple: the total API surface of XUL-based extensions is pretty much all of the internal APIs of Firefox, which means that any change anywhere in the code of Firefox breaks some extension accidentally. That's a compatibility burden that Mozilla could afford when the only competitor was IE, but it makes the development of Firefox much less nimble than that of Chrome & co. So a new, less invasive and more future-proof API is sorely needed.

nathancahill 10y ago
Surely the burden is on the extension developers and not Mozilla?
- Yoric 10y ago
  As a Firefox developer, whenever I make a change (and I mean pretty much any change to an API accessible through platform JS), I have two choices: 1/ either try and locate all the add-ons that will be broken, get in touch with their developers, be ignored by most of them, start several weeks of negotiation with those who do answer, then eventually, several months after my code is ready, land the change, and notice that Chrome has landed that same change a few months ago; 2/ ignore the add-on developers, improve Firefox immediately, but certainly break some add-ons, hence breaking the user experience of millions of users for no understandable reason. As you can imagine, neither solution is good and everybody suffers from either. WebExtensions condense all the instances of 1/ into a single point of time, hoping that we never again need to go through this painful dance.
  - deleted 10y ago
    [deleted]
  - ethbro 10y ago
    Is there a reason a both approach wasn't pursued with the current method being marked unsafe but still available for use? A la Rust mixing code but having to explicitly mark unsafe bits. For reasons listed in other comments above, the "we will expand WebExtensions API coverage based on current add-on needs" scares the shit out of me. I'm having visions of why I quit using Chrome because there was some download UX that could not be altered, and the default Google "one true way" of doing it irked the hell out of me.
    - Yoric 10y ago
      I'm pretty sure that there is some such mechanism. At least, I've seen patches related to such a mechanism. I don't remember the specifics and I can't find the documentation right now, but I seem to remember that there was something called the "WebExtensions Extension API" or something such that let developers access existing unstable APIs. It's probably somewhere. Note that in this case, we're not discussing (only) "unsafe" APIs but also "unstable" APIs that can change from one day to the next without warning.
  - alphapapa 10y ago
    > 1/ either try and locate all the add-ons that will be broken, get in touch with their developers, be ignored by most of them, start several weeks of negotiation with those who do answer, then eventually, several months after my code is ready, land the change, and notice that Chrome has landed that same change a few months ago (emphasis mine) And responding to that emphasis: so what?! People who use Firefox instead of Chrome do so for a reason! You're failing in two ways: 1) "breaking the user experience of millions of users for no understandable reason," and 2) turning Firefox into Chrome. If Firefox users wanted Chrome, they would already be using Chrome. They don't want Chrome, they just want Firefox to continue being Firefox, to keep working without breaking their add-ons that make their browser theirs! Why is this so hard for Mozilla to understand? The day Firefox stops supporting XUL extensions is the day I stop using Firefox. I've been using Firefox since it was Phoenix. I already have Chrome installed--I'm not using it, and there are reasons for that. You should meditate on this. Mozilla is slowly committing suicide. It's painful to watch, because it doesn't have to be. One of the great forces in the Internet's history is not going to be around in a few years. Firefox will live on, because of the MPL. But what a shame to destroy the organization that brought it into being. Such a waste. Oh well. If the Internet has taught us anything, it's taught us that, when it comes to software, developers are fungible. The phoenix will rise again.
    - Manishearth 10y ago
      > And responding to that emphasis: so what?! Presumably he's talking about web features when he says "Chrome landed that change a few months ago". This isn't copying Chrome, this is web compatability. You need that for websites to work.
    - johnny22 10y ago
      Mozilla's roadmap for the future is what's keeping me on the Firefox train, and not making me jump off it in favor of Chrome. In any case, you certainly don't speak for all Firefox users.
hucker 10y ago
So, will extensions like pentadactyl or Tree Style Tabs be able to exist after "some point in 2017"? Ignoring rewrite time etc., will there be APIs available to do what they do today?
- Yoric 10y ago
  The WebExtensions team has been very proactive, attempting to get in touch with add-on developers across the spectrum. If the add-on developers have responded, there's a 99% chance that new APIs will be available for their add-ons.
  - alphapapa 10y ago
    And what about extensions that have thousands upon thousands of users, still working fine, but haven't been updated in years because the author ran into real life? Is Mozilla going to dump those users on the street and then say, "Well, your author should have contacted us, we don't have time to implement your API now"?
    - cdmckay 10y ago
      I don't think that's unreasonable. They can't keep backwards compatibility forever because there might be some unmaintained extensions in the wild.
  - tn123 10y ago
    Sorry, but that is just wrong, Certain types of APIs are infeasible to provide, because mozilla is too time and resource constrained to invest major resources into spec'ing, implementing and maintaining "niche" APIs. So far, Firefox did not even manage to reach chrome parity, let alone bug parity. If you look at the Advisory Group meeting notes (in charge of new APIs AFAIK), there is almost nothing still: https://docs.google.com/document/d/1qCIUX0LavYixkzwan8IcSYeut4zQiCkJbrMVpSEm5Lk/edit# https://docs.google.com/document/d/1qCIUX0LavYixkzwan8IcSYeu... Sorry David, but you're kidding yourself here.
    - 10y ago
the8472 10y ago
> is pretty much all of the internal APIs of Firefox, But that's also what makes them more powerful than any other extension API. If your box is airtight then there is no out-of-the-box thinking. An almost trivial example: Internal APIs can inspect the current (as-enforced) sandboxing flags of an iframe. Which is not the same as the sandboxing HTML attributes on the frame, because those can be changed without effect after loading and also due to inheritance of sandboxing effects. This tiny tiny tidbit is useful when making content-filtering decisions. And it is just one among countless others.
- Yoric 10y ago
  Indeed, it's difficult to achieve a perfect balance here. That's one of the reasons the WebExtensions team has been very actively discussing with add-on developers to try and prioritize which APIs should be created/ported to WebExtensions. I don't remember specific numbers, but I seem to remember that pretty much all the extension points that had been requested by add-on developers were at least somewhere on the TODO list of WebExtensions. I hope that by the end of 2017, they will all be available, with a much cleaner API than their XUL/XPCOM counterpart, better tests and much better survival chances. Of course, some of the changes will require pretty drastic reimplementations by the developers. For instance, going from js-ctypes to the native bridge will require full reimplementation in a different programming language. On the upside, js-ctypes was really painful to use and the native bridge will let you use a much better language for the task. Say Rust :)
  - the8472 10y ago
    The native messaging API is not useful for addon developers. They only cater to application developers that ship a companion addon to their application. js-ctypes allowed an addon to access already-present native libs on the the host machine or bundled with the addon itself. Messaging only works if you can get users to install some external application in addition to your addon, which is a too-tall hurdle for small extensions. From my perspective those barely comparable. > That's one of the reasons the WebExtensions team has been very actively discussing with add-on developers to try and prioritize which APIs should be created/ported to WebExtensions. You are taking requests to keep existing uses supported, mostly for big, already established addons. My concern extends beyond that. Simply by having access to internals anyone can currently develop novel uses, even if they initially do not have a userbase. Those can only be prototyped by access to internals. Someone might not even have an idea if they don't know an API exists that could be leveraged to do it. In other words, "I can't let you do that, Dave" API design can stifle creativity. And it also introduces a bias in favor of already entrenched extensions, which is less open than the current approach.
gsnedders 10y ago
And, related to this, it makes it easier to move to Servo's layout code in the future, as it avoids Servo having to implement XUL and XBL.
- tn123 10y ago
  The current Firefox UI is XUL and XBL, tons and heaps of it. Re-implementing it in e.g. HTML is not an easy task, in particular not when you also want the result to look at least somewhat OS-native (took XUL itself ages to get there, btw). You also cannot do the OS-native look in HTML alone, you need support from the engine, which means servo has a some work ahead on that front too. So for the foreseeable future, servo is not an alternative to replace XUL/XBL anyway. mozilla said that themselves. Using servo to render the actual web pages inside the browser, that's another matter (once servo is considered stable enough, of course). To the add-on developer, this should not really make any difference anyway, XUL add-on, SDK add-on or WebExtension alike, as most add-ons for the most part will use the regular DOM APIs which servo has to provide anyway to interact with web stuff.
  - gsnedders 10y ago
    I don't know why the parent is voted down; it's a totally reasonable comment. It's definitely the case that the Firefox UI very much makes it impossible to move away from the current layout implementation at this point, and moving away would be a massive job. At the same time, the Firefox UI cannot move away from XUL/XBL until extensions no longer have free access to it, so this is definitely a first step that's relevant here. As for using Servo for web content, it's worthwhile pointing out that not only is it the direction Mozilla is taking (with Project Quantum, and progressively moving components from Servo into Gecko), but it would also be a technical challenge because web extensions have access to extra APIs and have security checks disabled in others.
tn123 10y ago
Firefox always broke stuff, since the very beginning. Mayor stuff, sometimes for no good reason, sometimes for very good reasons. Add-on developers learned to deal with it. A lot of add-on developers now have an alternative in WebExtensions, which will ease that pain indeed. But those developers that cannot or will not use WebExtensions (e.g. I will not/can not port most/any of my add-ons incl. DownThemAll!), but probably would manage breaking changes (I did that for more than a decade now), are left in the cold, rainy dark now.
Macha 10y ago
> which means that any change anywhere in the code of Firefox breaks some extension accidentally So to fix this they're going to break every extension. I think it's a fair assumption given how long the current extension API has been around that there will be more extensions that will die to disinterest or inability to move to WebExtensions than have been broken by all firefox releases from 4.0 to date.

by Yoric 10y ago

nathancahill 10y ago

Surely the burden is on the extension developers and not Mozilla?

Yoric 10y ago
As a Firefox developer, whenever I make a change (and I mean pretty much any change to an API accessible through platform JS), I have two choices: 1/ either try and locate all the add-ons that will be broken, get in touch with their developers, be ignored by most of them, start several weeks of negotiation with those who do answer, then eventually, several months after my code is ready, land the change, and notice that Chrome has landed that same change a few months ago; 2/ ignore the add-on developers, improve Firefox immediately, but certainly break some add-ons, hence breaking the user experience of millions of users for no understandable reason. As you can imagine, neither solution is good and everybody suffers from either. WebExtensions condense all the instances of 1/ into a single point of time, hoping that we never again need to go through this painful dance.
- deleted 10y ago
  [deleted]
- ethbro 10y ago
  Is there a reason a both approach wasn't pursued with the current method being marked unsafe but still available for use? A la Rust mixing code but having to explicitly mark unsafe bits. For reasons listed in other comments above, the "we will expand WebExtensions API coverage based on current add-on needs" scares the shit out of me. I'm having visions of why I quit using Chrome because there was some download UX that could not be altered, and the default Google "one true way" of doing it irked the hell out of me.
  - Yoric 10y ago
    I'm pretty sure that there is some such mechanism. At least, I've seen patches related to such a mechanism. I don't remember the specifics and I can't find the documentation right now, but I seem to remember that there was something called the "WebExtensions Extension API" or something such that let developers access existing unstable APIs. It's probably somewhere. Note that in this case, we're not discussing (only) "unsafe" APIs but also "unstable" APIs that can change from one day to the next without warning.
- alphapapa 10y ago
  > 1/ either try and locate all the add-ons that will be broken, get in touch with their developers, be ignored by most of them, start several weeks of negotiation with those who do answer, then eventually, several months after my code is ready, land the change, and notice that Chrome has landed that same change a few months ago (emphasis mine) And responding to that emphasis: so what?! People who use Firefox instead of Chrome do so for a reason! You're failing in two ways: 1) "breaking the user experience of millions of users for no understandable reason," and 2) turning Firefox into Chrome. If Firefox users wanted Chrome, they would already be using Chrome. They don't want Chrome, they just want Firefox to continue being Firefox, to keep working without breaking their add-ons that make their browser theirs! Why is this so hard for Mozilla to understand? The day Firefox stops supporting XUL extensions is the day I stop using Firefox. I've been using Firefox since it was Phoenix. I already have Chrome installed--I'm not using it, and there are reasons for that. You should meditate on this. Mozilla is slowly committing suicide. It's painful to watch, because it doesn't have to be. One of the great forces in the Internet's history is not going to be around in a few years. Firefox will live on, because of the MPL. But what a shame to destroy the organization that brought it into being. Such a waste. Oh well. If the Internet has taught us anything, it's taught us that, when it comes to software, developers are fungible. The phoenix will rise again.
  - Manishearth 10y ago
    > And responding to that emphasis: so what?! Presumably he's talking about web features when he says "Chrome landed that change a few months ago". This isn't copying Chrome, this is web compatability. You need that for websites to work.
  - johnny22 10y ago
    Mozilla's roadmap for the future is what's keeping me on the Firefox train, and not making me jump off it in favor of Chrome. In any case, you certainly don't speak for all Firefox users.

hucker 10y ago

So, will extensions like pentadactyl or Tree Style Tabs be able to exist after "some point in 2017"? Ignoring rewrite time etc., will there be APIs available to do what they do today?

Yoric 10y ago
The WebExtensions team has been very proactive, attempting to get in touch with add-on developers across the spectrum. If the add-on developers have responded, there's a 99% chance that new APIs will be available for their add-ons.
- alphapapa 10y ago
  And what about extensions that have thousands upon thousands of users, still working fine, but haven't been updated in years because the author ran into real life? Is Mozilla going to dump those users on the street and then say, "Well, your author should have contacted us, we don't have time to implement your API now"?
  - cdmckay 10y ago
    I don't think that's unreasonable. They can't keep backwards compatibility forever because there might be some unmaintained extensions in the wild.
- tn123 10y ago
  Sorry, but that is just wrong, Certain types of APIs are infeasible to provide, because mozilla is too time and resource constrained to invest major resources into spec'ing, implementing and maintaining "niche" APIs. So far, Firefox did not even manage to reach chrome parity, let alone bug parity. If you look at the Advisory Group meeting notes (in charge of new APIs AFAIK), there is almost nothing still: https://docs.google.com/document/d/1qCIUX0LavYixkzwan8IcSYeut4zQiCkJbrMVpSEm5Lk/edit# https://docs.google.com/document/d/1qCIUX0LavYixkzwan8IcSYeu... Sorry David, but you're kidding yourself here.
  - 10y ago

the8472 10y ago

> is pretty much all of the internal APIs of Firefox, But that's also what makes them more powerful than any other extension API. If your box is airtight then there is no out-of-the-box thinking. An almost trivial example: Internal APIs can inspect the current (as-enforced) sandboxing flags of an iframe. Which is not the same as the sandboxing HTML attributes on the frame, because those can be changed without effect after loading and also due to inheritance of sandboxing effects. This tiny tiny tidbit is useful when making content-filtering decisions. And it is just one among countless others.

Yoric 10y ago
Indeed, it's difficult to achieve a perfect balance here. That's one of the reasons the WebExtensions team has been very actively discussing with add-on developers to try and prioritize which APIs should be created/ported to WebExtensions. I don't remember specific numbers, but I seem to remember that pretty much all the extension points that had been requested by add-on developers were at least somewhere on the TODO list of WebExtensions. I hope that by the end of 2017, they will all be available, with a much cleaner API than their XUL/XPCOM counterpart, better tests and much better survival chances. Of course, some of the changes will require pretty drastic reimplementations by the developers. For instance, going from js-ctypes to the native bridge will require full reimplementation in a different programming language. On the upside, js-ctypes was really painful to use and the native bridge will let you use a much better language for the task. Say Rust :)
- the8472 10y ago
  The native messaging API is not useful for addon developers. They only cater to application developers that ship a companion addon to their application. js-ctypes allowed an addon to access already-present native libs on the the host machine or bundled with the addon itself. Messaging only works if you can get users to install some external application in addition to your addon, which is a too-tall hurdle for small extensions. From my perspective those barely comparable. > That's one of the reasons the WebExtensions team has been very actively discussing with add-on developers to try and prioritize which APIs should be created/ported to WebExtensions. You are taking requests to keep existing uses supported, mostly for big, already established addons. My concern extends beyond that. Simply by having access to internals anyone can currently develop novel uses, even if they initially do not have a userbase. Those can only be prototyped by access to internals. Someone might not even have an idea if they don't know an API exists that could be leveraged to do it. In other words, "I can't let you do that, Dave" API design can stifle creativity. And it also introduces a bias in favor of already entrenched extensions, which is less open than the current approach.

gsnedders 10y ago

And, related to this, it makes it easier to move to Servo's layout code in the future, as it avoids Servo having to implement XUL and XBL.

tn123 10y ago
The current Firefox UI is XUL and XBL, tons and heaps of it. Re-implementing it in e.g. HTML is not an easy task, in particular not when you also want the result to look at least somewhat OS-native (took XUL itself ages to get there, btw). You also cannot do the OS-native look in HTML alone, you need support from the engine, which means servo has a some work ahead on that front too. So for the foreseeable future, servo is not an alternative to replace XUL/XBL anyway. mozilla said that themselves. Using servo to render the actual web pages inside the browser, that's another matter (once servo is considered stable enough, of course). To the add-on developer, this should not really make any difference anyway, XUL add-on, SDK add-on or WebExtension alike, as most add-ons for the most part will use the regular DOM APIs which servo has to provide anyway to interact with web stuff.
- gsnedders 10y ago
  I don't know why the parent is voted down; it's a totally reasonable comment. It's definitely the case that the Firefox UI very much makes it impossible to move away from the current layout implementation at this point, and moving away would be a massive job. At the same time, the Firefox UI cannot move away from XUL/XBL until extensions no longer have free access to it, so this is definitely a first step that's relevant here. As for using Servo for web content, it's worthwhile pointing out that not only is it the direction Mozilla is taking (with Project Quantum, and progressively moving components from Servo into Gecko), but it would also be a technical challenge because web extensions have access to extra APIs and have security checks disabled in others.

tn123 10y ago

Firefox always broke stuff, since the very beginning. Mayor stuff, sometimes for no good reason, sometimes for very good reasons. Add-on developers learned to deal with it. A lot of add-on developers now have an alternative in WebExtensions, which will ease that pain indeed. But those developers that cannot or will not use WebExtensions (e.g. I will not/can not port most/any of my add-ons incl. DownThemAll!), but probably would manage breaking changes (I did that for more than a decade now), are left in the cold, rainy dark now.

Macha 10y ago

> which means that any change anywhere in the code of Firefox breaks some extension accidentally So to fix this they're going to break every extension. I think it's a fair assumption given how long the current extension API has been around that there will be more extensions that will die to disinterest or inability to move to WebExtensions than have been broken by all firefox releases from 4.0 to date.