16 ms·

The Future of Developing Firefox Add-ons

281 points by zawaideh 11y ago

shock 11y ago
> The Beta and Release versions of Firefox based on 42 and above (Beta 42 will be released at the same time as Firefox 41) will remove the preference that allows unsigned extensions to be installed, and will disable and/or prevent the installation of unsigned extensions. This is very bad news for me. I'm a power user that prefers the balance of new features/chance of breakage that the Beta channel offers and I take full responsibility for the addons I install and the security decisions I make. I don't need Mozilla to be "defending" me in this case.
- zawaideh 11y ago
  Fully agree. On Mac OS X you can still run unsigned apps, but you have to be savvy enough to do so. Mozilla should at the very least adopt such an approach.
  - geekingfrog 11y ago
    xpinstall.signatures.required should be the setting you're looking for.
    - super_mario 11y ago
      This option will be removed from about:config in Firefox 42.
    - shock 11y ago
      That's the option I'm currently using and that Mozilla plans to remove in Firefox 42.
      - CmdrKrool 11y ago
        Could someone make an extension to re-enable this config option? And... would Mozilla agree to sign it? (Since, you know, the standard response over the years to users complaining about removed functionality in Firefox has been, "use an extension")
        shock 11y ago
        I doubt an extension could do that since the signing mechanism needs to be secure, otherwise it would be pointless.
        nightpool 11y ago
        no, because then any malware would immediately install that extension first, and then flip the about:config bit on the filesystem, and then install their extension, and then you're right back where you were before signing.
  - ianbicking 11y ago
    A big problem for a lot of Firefox users is addons that are side-loaded into a profile. Like when you download some junk and it comes with an installer that injects an addon into your profile. This is a good expose on what even a seemingly legitimate site like download.com does: http://www.howtogeek.com/198622/heres-what-happens-when-you-install-the-top-10-download.com-apps/ http://www.howtogeek.com/198622/heres-what-happens-when-you-... (and several of the malware examples in that article are side-loaded addons). Unfortunately hoops aren't enough to fix this problem, because hoops generally involve some flag that you've gone through the hoop, and the installer can easily fake that.
    - ptx 11y ago
      Couldn't those installers patch Firefox to remove the signing requirement? Or, if they don't get sufficient privileges to modify the executable, patch the user's Firefox process in memory?
      - Tobu 11y ago
        Chrome did a similar change which led to a pretty spectacular drop: http://blog.chromium.org/2015/05/continuing-to-protect-chrome-users-from.html http://blog.chromium.org/2015/05/continuing-to-protect-chrom...
      - ianbicking 11y ago
        Yeah, this might end up being just a salvo in a longer battle. But maybe part of the problem is that some of these malware authors are lying to themselves and believe they are just grayhat hackers, and once you start patching executables it becomes a bit clearer you are a blackhat. So far download.com isn't distributing actual rootkits. They could of course. And yet still they probably won't. Relatedly I did notice when putting my own addon through the signing process that there was a checkbox specifically for sideloaded addons, with the implication that the checks would be even more stringent. I'm not sure if that's enforced or not, or how.
    - deno 11y ago
      How is that Mozilla’s problem? If you close all the “hoops” the rogue installer can just simply replace Firefox with its own build of “Firefox.” I truly don’t understand why Mozilla is trying to do Microsoft’s job.
- sonnyp 11y ago
  Use Firefox Beta or Firefox Nightly
  - shock 11y ago
    I'm already using Firefox Beta. I don't want to be using Firefox Nightly.
    - brighteyes 11y ago
      As others said elsewhere, mozilla will provide builds of Beta that do not have this issue. It's just that the default build will.
  - sandyarmstrong 11y ago
    The preference is being removed from Beta, as quoted above. Nightly is just not a great answer for a "power user".
  - gcb0 11y ago
    but i actually do work. I'm not testing new ff releases all the time. i also run Aurora for that. now you say release/sign your extensions.... well they mostly contain internal data and URLs. no way I'm publishing any of those.
    - nightpool 11y ago
      You don't need to publish extensions to get them signed, AMO will sign unlisted extensions that are submitted. this doesn't really change the situation for enterprise users though.
      - detaro 11y ago
        Allow enterprise users to generate firefox executables with additional trusted certificates and distribute that on their machines instead of the original?
- nine_k 11y ago
  «The Nightly and Developer Editions of Firefox based on 42 and above will retain the preference to disable signing enforcement, allowing the development and/or use of unsigned add-ons in those versions» So I think running the Developer Edition (which I expect to be much more stable than Nightly) is probably your best bet.
  - shock 11y ago
    The thing is, I'm not a web developer and I don't think I should be forced to use the Developer Edition just so I can remain in charge of what I install in my browser. Now that I'm writing this it occurs to me that after this change it's not really my browser anymore, is it?
    - catern 11y ago
      Use Iceweasel or GNU Icecat?
      - shock 11y ago
        Thanks for the suggestion! That's what I'll prolly end up doing although neither of them are in the Ubuntu repos.
    - outworlder 11y ago
      Are you sure you are a 'power user', then?
      - shock 11y ago
        I'm not sure what you mean, but are you suggesting that if I'm a savvy driver I should just drive prototype cars?
        nightski 11y ago
        Are you suggesting that the developer edition is merely a prototype and not a production browser?
- Animats 11y ago
  One reason for add-on signing is that there's a major attack on Firefox using stolen add-on IDs to insert malware. This started in early 2015, and one of my add-ons has about one-third bogus versions out there. They all have different random version numbers, typically above 1000. Those are about to get flushed out of the ecosystem. Whether add-on signing is part of a power trip at Mozilla to enforce a walled garden with Mozilla-favorable policies remains to be seen. When Mozilla blocks an add-on which disables Pocket or Sync or Hello, we'll know that AMO has turned to the dark side.
  - makomk 11y ago
    That could presumably be solved by allowing developers to sign their own add-ons and tying the ID to the key they used to sign it - it doesn't require a centralised signing system of the kind Mozilla introduced.
superkuh 11y ago
Well, this is all terrible. They mention having to use the nightly or developers releases instead of their walled garden versions. But both of those are unstable and very crashy. And how likely are they to keep the unbranded version up and updated as time goes on? And getting rid of the entire firefox add-ons community is just insane. The add-ons are what makes firefox good. It's why people use Firefox. I guess if they just want us to use Chrome this series of changes will work great.
- eli 11y ago
  Firefox Developer Edition is for web developers, not for browser developers. It isn't like a nightly -- it's stable. https://www.mozilla.org/en-US/firefox/developer/ https://www.mozilla.org/en-US/firefox/developer/
  - superkuh 11y ago
    Have you used it? After I heard about the changes coming down the line in 41 a week or so back I immediately downloaded it and started configuring it to be my new main browser. The only problem was that it crashed constantly. It's just anecdotal but my personal experience backs up what I've said here.
    - the8472 11y ago
      Well, to give a counter-anecdote: I've been using nightly for years and only experience severe problems maybe a handful times per year, the rest of the time it works fine. And that's with several extensions and many tabs.
    - ohkine 11y ago
      FYI, i have used Aurora/DevEdition almost exclusively (outside of testing) on at least a dozen different Windows and OS X machines ever since the Aurora channel was created and i have never once had a serious problem. Occasionally i find little visual glitches or whatever, but it rarely ever crashes and i never get data loss or anything severe like that.
  - 11y ago
fweespeech 11y ago
The title is a bit misleading: > We are implementing a new extension API, called WebExtensions—largely compatible with the model used by Chrome and Opera—to make it easier to develop extensions across multiple browsers. This is basically the creation of a new, multi-browser API standard for browser extensions. This isn't them just adopting a single competitor's ecosystem. There is also a slim chance IE and Safari will join the plugin ecosystem. EDIT: Ty mods, this title is more reasonable.
- amyjess 11y ago
  > There is also a slim chance IE and Safari will join the plugin ecosystem. You mean Edge. IE development is pretty much dead except for maintenance releases, and it now exists solely to handle legacy websites (read: corporate dinosaurs that rely on ActiveX).
  - fweespeech 11y ago
    Edge is basically IE in purpose and function. I don't really buy into the rebrand.
- makomk 11y ago
  Recent releases of Opera are just a reskinned version of Chrome. This is exactly them adopting a single competitor's ecosystem, it's just that Opera did the same thing even more completely a while ago.
- superkuh 11y ago
  That's true. But that isn't what most users care about regarding this change. Just look at these comment threads: users care about the power-user extensions being forced out. There's a definite drop of support. Firefox is dropping the add-ons that made it special. The title now is just spin.
annoyingdisb 11y ago
WebExtensions is very good news. One of the biggest pains is to develop extensions compatible both with FF and Chrome so it would make our lives a lot easier.
mrbig4545 11y ago
It doesn't mention addon permissions, which I would assume is something WebExtensions has, since that's how addons work in chrome. At least I hope this is the case, lack of permissions in firefox addons is a little scary, and probably one of the reasons I have the minimum addons installed Anyone have more info on this?
- snowwolf 11y ago
  Same permissions model as Chrome - https://wiki.mozilla.org/WebExtensions#Permission_Model https://wiki.mozilla.org/WebExtensions#Permission_Model
  - mrbig4545 11y ago
    Excellent, that's what I wanted to hear! Thanks
- Ded7xSEoPKYNsDd 11y ago
  I'm much more relaxed using Firefox add-ons from addons.mozilla.org than Chrome extensions because Mozilla has actual people making sure that the add-ons don't do any nefarious things. (Or at least forces them to disclose that properly.) On the other hand, getting hidden adware or password keyloggers into the Chrome store is no problem at all.
tetraodonpuffer 11y ago
I was under the impression that add-ons like ublock / umatrix were possible only in firefox due to its very permissive add-on model, if mozilla is going to deprecate XUL / XPCOM would it mean this kind of add-on won't be possible anymore?
- timdafweak 11y ago
  That's the first thought that came to my mind as well. Addons like Fire Gestures and Easy Dragtogo are what keep me on Firefox. Chrome can't implement those apparently, and now it seems that support for them will be deprecated too.
- snowwolf 11y ago
  uBlock - https://chrome.google.com/webstore/detail/ublock-origin/cjpalhdlnbpafiamejdnhcphjbkeiagm https://chrome.google.com/webstore/detail/ublock-origin/cjpa... uMatrix - https://chrome.google.com/webstore/detail/umatrix/ogfcmafjalglgifnmanfmnieipoejdcf https://chrome.google.com/webstore/detail/umatrix/ogfcmafjal...
  - tetraodonpuffer 11y ago
    thanks for the clarification, I haven't looked at add-ons for other browsers for quite a while, and at the time I remember discussions about adblock not being possible to be done anywhere else like in FF due to the add-on model, glad to see this does not seem to be the case anymore
    - falcolas 11y ago
      I think the big difference is being able to pre-emptively block/modify requests, vs. changing what is displayed after the fact.
      - tetraodonpuffer 11y ago
        that was what I thought as well, however I went to the umatrix github page and if you look at the top it links this page[1] that discusses how umatrix needs permission to disable prefetching so no network connections are made for blocked sites, which seems to imply it can do the pre-emptive blocking as opposed to just hiding of elements. I am wondering though now if I am mixing things up in my brain and the issues were with safari add-ons as opposed to chrome/chromium: there is no umatrix for safari[2] that I can see, ublock seems available but not ublock origin, but I am not sure if ublock on safari just hides or actually pre-emptively blocks. [1] https://github.com/gorhill/uMatrix/releases/tag/0.9.1.2 https://github.com/gorhill/uMatrix/releases/tag/0.9.1.2 [2] https://github.com/gorhill/uMatrix/issues/96 https://github.com/gorhill/uMatrix/issues/96
deleted 11y ago
[deleted]
kibwen 11y ago
Standardizing the basic means of browser extension is something that I've been eagerly awaiting ever since Microsoft announced that Edge will support both Firefox (Jetpack) extensions and Chrome extensions. But how will future versions of Firefox handle the extensions that just can't exist in Chrome, such as NoScript and Tree Style Tabs? EDIT: I'm also excited at the idea that this could give Servo a running start at an extensions story, since Servo will never in a million years support XUL or XPCOM and hence all non-Jetpack Firefox addons are destined to fail there anyway.
- micro-ram 11y ago
  I use ScriptSafe (formerly ScriptNo) in Chrome similar to NoScript on Firefox. Also check out uMatrix. https://code.google.com/p/scriptno/ https://code.google.com/p/scriptno/
  - jb613 11y ago
    For one, it only a subset of Noscript: "A simple extension that brings SOME OF NoScript's functionality to Chrome" Secondly, in order to achieve its goal, it's relying on a hack: ... if (getElSrc(this) && getElSrc(this).toLowerCase().substr(0,11) != 'javascript:' && getElSrc(this).toLowerCase().substr(0,17) != 'chrome-extension:') ... Not taking anything away from this extension, just that this illustrates what everyone's saying - concerns about reduced functionality.
deleted 11y ago
[deleted]
nocman 11y ago
"we will require all extensions to be validated and signed by Mozilla starting in Firefox 41" I hope there is an "opt out" option to this for people who know what they are doing. I understand the reasoning behind it, but what about an extension I write just for myself that I don't wish to share with Mozilla? I don't particularly like having that option taken from me. Yeah, I know, I could edit the source and work around it -- but based on past attempts to just build firefox, that could be a real pain.
- the8472 11y ago
  There will be unbranded builds that provide that option, branded builds will enforce signature verification.
  - nocman 11y ago
    Are you referring to iceweasel? Or are you referring to an unbranded build provided by Mozilla? I honestly don't remember any other browsers that have the Mozilla branding removed, but I haven't really tried to find any.
    - lol768 11y ago
      Mozilla will provide these unbranded builds in the en-US locale. See "What are my options if I want to install unsigned extensions in Firefox?" in the FAQ for more info: https://wiki.mozilla.org/Addons/Extension_Signing#FAQ https://wiki.mozilla.org/Addons/Extension_Signing#FAQ
antman 11y ago
The last Symbian in Nokia phones was also very strict with signed applications. I bypassed it, but it is my impression that most people did't bother.
shwetank 11y ago
We at Opera have called on for a single (or at leat a shared) API for making browser extensions, which I think will benefit the developer community immensely (instead of making one set for each browser). I think now the time is right to take a look again at NEX https://dev.opera.com/blog/introducing-nex/ https://dev.opera.com/blog/introducing-nex/ and standardising core parts of browser extensions.
super_mario 11y ago
And this is how Google killed Firefox. Why do people use Firefox? For extensions. What breaks extensions, frequent updates and extension API changes. Google managed to suck Mozilla into frequent releases and now extension API changes that make Firefox yet another generic easy to substitute browser. Wow, just wow.
- uxcn 11y ago
  Frequent releases aren't a bad thing, per se. Although, huge API changes like this, without a valid plan for supporting existing ones a large community depends on seems like a disaster in the making. The impression I get is that Mozilla wants to be more involved in the user experience around their codebase, but personally I preferred firefox's lack of involvement. I think the UI is poorly designed and getting worse, but as long as it was easy to modify, it wasn't an issue. The real value in firefox for me is gecko. Most other things largely get in the way, and it seems like that's what's becoming the focus. I can understand the need for a better designed add-on API, but there should probably be a non-compulsory reason for people to switch.
- MichaelGG 11y ago
  I use Firefox because it's open and more pro-user than Google is. And Mozilla's work on Rust is incredibly important too. (Rust manages to accomplish what decades of effort and loads of money on C analyzers and mitigation techniques fail to.) So it's important, ethically, to support Firefox.
jpatel3 11y ago
There used to be a time when I loved firefox..the new versions are slow and sluggish. If I open the developer console, its super slow.
- Tobu 11y ago
  The developer console can disable the cache so that you can edit websites live, is that what you're seeing? Also, I wonder if it's still slow if you restart with extensions disabled. There's a lot of hidden interactions in the current model.
amyjess 11y ago
I'm really disappointed with them deprecating XUL extensions. I use a number of extensions that extensively modify the UI (e.g. Tab Mix Plus), and honestly I'd rather just stick with an older version of Firefox than use Firefox without these extensions.
- Tobu 11y ago
  They're using the WebExtension model of isolated extensions with permissions. They're not going to limit themselves to any competitor's API, they'll build a superset by consulting with the developers of popular extensions. Tab Mix Plus being the 15th most popular extension, it's pretty certain they'll be consulted on the new APIs. Quoting from the announcement: > A major challenge we face is that many Firefox add-ons cannot possibly be built using either WebExtensions or the SDK as they currently exist. Over the coming year, we will seek feedback from the development community, and will continue to develop and extend the WebExtension API to support as much of the functionality needed by the most popular Firefox extensions as possible.
keypusher 11y ago
Disabling unsigned extensions without any opt-in is a terrible decision. Putting up barriers to entry for addon developers in a browser that survives primarily based on the addon ecosystem is suicidal. Addon developers do not want to run unstable alpha channel builds, they don't want to have to manage multiple profiles, they don't want to build Firefox from scratch because the version they need is not available via a package manager. I really don't care about the rest of these changes, but they need to rethink their stance on unsigned extensions.
- nocman 11y ago
  I agree. One possible workaround would be to provide a way to add keys from which you would accept extensions. Then as part of the extension development process, you could sign your extension with your key when you are ready to install it. If the issue Mozilla is really concerned about is security, this should be an acceptable solution.
  - coldpie 11y ago
    I think you have a good idea, but > If the issue Mozilla is really concerned about is security, this should be an acceptable solution. I don't know what you're implying here. That they're not concerned about security? What are they concerned about?
    - nocman 11y ago
      No, indeed I do hope that security is the primary thing they are concerned about. But it is possible they have other motivations (like control). I hope that is not the case, but I think it would be foolish to not even consider the possibility.
  - TazeTSchnitzel 11y ago
    > One possible workaround would be to provide a way to add keys from which you would accept extensions. Then malicious apps will just sideload new keys.
- 11y ago
jasonhansel 11y ago
I switched to Firefox in part because XUL-based extensions can heavily customize the user interface. Things like Tile Tabs, Tab Mix Plus, and other extensions have been extremely useful to me. Despite my dislike of XUL as a language, I'm sad to see XUL extensions go; I suspect that WebExtensions will, like Google Chrome extensions, be much more limited. In fact, I had always hoped that FF would move in the opposite direction, and split itself apart into a bundle of extensions, so that even more customization could be possible. I've also always enjoyed being able to run the latest versions of extensions, which sometimes take a while to get Mozilla's approval. Are there any plans to maintain a fork of Firefox that will not include these changes?
- jasonhansel 11y ago
  In short, I would like to find a web browser that follows the Unix philosophy to a greater extent than Firefox/Chrome/IE.
  - amk_ 11y ago
    Vivaldi? Midori?
    - jasonhansel 11y ago
      IIRC, Vivaldi uses Chrome extensions, which have the same limitations as the new Firefox WebExtensions. Not sure about Midori.
  - catern 11y ago
    I don't really know why, but I have some small optimism that Servo might enable such a browser. The only other candidate browser engine is Webkit, which is already too huge to be part of a small Unixy browser. Maybe Servo, as a project that people are actively hacking on, might work. Alternatively, maybe https://github.com/breach/breach_core https://github.com/breach/breach_core though their website is down, so maybe the project is dead...
    - 11y ago
tenfingers 11y ago
You know, I had plenty of reasons to list about how useless signed extensions are for what they're trying to achieve... I'm even _already_ running an "unbranded" firefox in all my devices (iceweasel, fennec), for the same reasons I have to run chromium, so I won't even be _directly_ affected.... But there's only one thing I really want to say to Mozilla right now, as a developer: Fuck you Mozilla. And there's another, as an user of which most extensions are unsigned: Fuck you again, Mozilla. aaah feels better.
- jimmaswell 11y ago
  I agree, the web gets less and less open and free by the minute. It's actively hostile to user choice half the time.
  - tenfingers 11y ago
    When Mozilla will decide, apple/google style, what is and what is not acceptable as an extension for their browser, people will maybe realize that this is just the tipping point. But maybe that won't be necessary anyway. By adopting a very limiting standard for extension development and dropping xul (which might be a good idea for other reasons though), there won't be any significant difference between firefox and (say) chrome. A few tweaks in the browser frame won't attract masses of people. Switching from Chrome to Firefox on Android require a pretty big incentive. Right now, I'm on firefox only for the extensions. I have really no other compelling reasons.
fra 11y ago
I worry that extensions that implement their own navigation and user experience will no longer be possible. I use Vimperator extensively and would hate to see it go. Chrome does have Vimium, but it is quite clunky and limited compared to the couple of Firefox solutions.
__david__ 11y ago
So on the one hand I love that they're moving forward. Sometimes it's good to get rid of cruft (and boy is XPCOM crufty). On the other hand, the rich extension ecosystem is one of the highlights of Firefox. I honestly don't know what I'll do if my TreeStyleTab extension is disabled. I lucked out because the Beta version has the preference to use unsigned extensions. But that extension is so fundamental to my Firefox experience that if they remove that preference in the new version then I think I'll have no choice but to turn off updates and live with my current version indefinitely. And that doesn't make me happy.
- jasonhansel 11y ago
  Furthermore, I doubt that such extensions will work without XUL/XPCOM, at least if WebExtensions work like Chrome extensions.
  - nwah1 11y ago
    That's why they're also working on browser.html so vigorously https://github.com/mozilla/browser.html https://github.com/mozilla/browser.html Web standards are fully capable of rendering entire user interfaces now. GUI toolkits are just needless dependencies for web rendering engines.
    - fabrice_d 11y ago
      Exactly. Once all your front-end is in html, including the part that manages tabs, nothing prevent a WebExtension to implement TreeStyleTabs. Also note that the same extension support is landing in Firefox OS (we are working on the missing apis), and will let you install the same extensions everywhere. I understand people mourning xpcom access. You can do fun things with that, but I've also seen my share of horrors when I was reviewing add-ons (let's override the http protocol handler, what could go wrong!).
      - wldcordeiro 11y ago
        Except for people losing interest in developing for the platform due to all the API churn. By the time all this lands no one will care to implement TreeStyleTabs.
dannysu 11y ago
I still don't like that the AMO review process can take weeks and months. Mozilla even says it themselves! But hopefully with WebExtension and a permission model things will get easier for getting through reviews.
simonster 11y ago
It used to be that Firefox extensions could have the same capabilities as Firefox itself. It seems that this move is relegating them to second-class status. Here's a list of things missing from the Chrome/WebExtensions API that our extension currently does: - Customization of the browser UI beyond a single, simple toolbar button or a few other specially implemented widgets. - Reading/writing arbitrary files to the file system. There is chrome.fileSystem, but it's limited in what it allows, and it isn't available to extensions, only Chrome apps. - Interfacing with other applications. This typically requires using platform-native APIs, which was possible with js-ctypes (https://developer.mozilla.org/en-US/docs/Mozilla/js-ctypes https://developer.mozilla.org/en-US/docs/Mozilla/js-ctypes). Chrome has a socket API, but it's not really the best way to do IPC, and it isn't available to extensions anyway. - Some kind of SQL database. Firefox has an SQLite interface (MozStorage), but it's not part of the WebExtensions API. Chrome actually has WebSQL, but Firefox never implemented that (with good reason, IMO; it's tied to a SQLite and shouldn't be used on the web). I guess you'd better like IndexedDB. - Native-looking UI widgets. This is certainly possible to do in HTML, but it's not always so easy. For example, we have yet to find any reasonable HTML-based replacement for our tree view that's both visually appealing on all platforms and reasonably performant with thousands of items. (If you have suggestions, let us know!) I guess Mozilla's viewpoint is that, since everyone is already supporting Chrome, they don't need these things. However, for our extension, the difference between the Chrome and Firefox implementations is that the Chrome implementation needs to talk to a separate app, while the Firefox implementation can do everything itself. Firefox used to give us a very powerful toolkit for writing apps, the same toolkit they used to create Firefox. Now it looks like all we'll have is a toolkit for writing simple browser extensions. I think many people use Firefox because they can customize it the way they want to. Soon you won't be able to customize Firefox any more than Chrome. Maybe Mozilla is banking on Servo being so fast/secure that people will use it over Chrome even when all the other advantages are gone.
- deleted 11y ago
  [deleted]
- spaceribs 11y ago
  The customization element was nice, but I feel like most of these issues will be addressed by future developments. With everyone using close to the same API, we have to move backward a bit, but one browser implementing a feature like file access means developers going to other browsers and saying "Why can't I do the same thing from the other guy?" While this somewhat exists already, it will be much louder if they aren't entirely different plugin architectures and used as a developer excuse.
scottjad 11y ago
A funny comment on the post: "BTW, if you really want to show us that you trust this much in these new WebExtensions, the first ones to appear at AMO should be Pocket and Hello. Remove that code from the core Firefox and put it where it always should have been: an extension that anyone interested can easily install." And a more serious comment from a developer of DownThemAll!: "I was thinking of abandoning add-on development for a while now, mostly because of the Walled Garden signing approach that went live, which I strongly objected to and still strongly object to… I might have come to terms with it, once I see it play out in an actual implemention… But “deprecating” XUL-based add-ons with XPCOM access takes the cake. Once that happens, I will abandon ship for sure. Simply because I cannot continue developing most add-ons at all as they will not and cannot fit into any “WebExtensions” API. The flexibility of what XUL-based add-ons can do IS the major selling point of the Firefox add-ons ecosystem and therefore IS one of the last remaining selling points of Firefox itself that isn’t purely ideological. In comparison, the APIs that Chrome and competitors offer, that the Firefox Jetpack/ Add-on SDK offers, are just… toys. To give a little background about myself to show that I’m not just the random hater shooting a drive-by comment: I wrote some more or less successful add-ons in the past, including DownThemAll!, and reviewed many, many add-ons as an AMO volunteer." https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/comment-page-1/#comment-218580 https://blog.mozilla.org/addons/2015/08/21/the-future-of-dev...
- dafrankenstein2 11y ago
  or if firefox wants to keep it in the core, they should maintain high attention on Pocket( ensuring there is no security flow)
- wvenable 11y ago
  I use Tab Mix Plus for multi-row tabs in Firefox. It's so important to how I browse that it's the main reason why I use Firefox. If it goes away, then I have no reason to use Firefox.
  - thom_nic 11y ago
    I was thinking the same thing. Tab Mix Plus sounds like one of those extensions that might not be doable under the new API... Which would explain why there's no chrome version. Also the main reason why I use Firefox as well... This window has 20 tabs open :)
dafrankenstein2 11y ago
though its late, security review is a great thing! (maybe firefox realized its urgency after a major security flow found in Pocket.)
scottjad 11y ago
They want to kill XUL for Firefox, so they must first kill XUL for add-ons so that the add-on situation sucks so bad with XUL Firefox that people don't lose anything by moving to non-XUL Firefox. And once they kill XUL, they can kill gecko, the maintenance of which is the bane of their job.
- holygoat 11y ago
  That's not the plan. We've identified that XUL is a growing impediment to Firefox's continued success. Exactly what that means (there are dozens of reasons and dozens of ways forward), and how we're going to tackle it, is a big topic that we're digging into. Yes, removing XUL implies that XUL-based add-ons are not going to last forever. That doesn't mean there won't be a path from here to there: everyone involved recognizes that add-ons are important, and we're increasingly going to be shipping parts of Firefox itself using add-on mechanisms. And I haven't seen anyone seriously consider killing Gecko: it continues to be awesome, and one of the motivations for deXULification is to allow our platform developers the freedom to only focus on supporting HTML UIs, not a mix of HTML and XUL.
slasaus 11y ago
"A major challenge we face is that many Firefox add-ons cannot possibly be built using either WebExtensions or the SDK as they currently exist. Over the coming year, we will seek feedback from the development community, and will continue to develop and extend the WebExtension API to support as much of the functionality needed by the most popular Firefox extensions as possible." So to all extension developers leaning on the current permissive features or XUL/XPCOM, please contact Mozilla and help them with finalizing their WebExtension API in the upcoming year. Also, in the future if all XUL in Firefox is replaced by browser.html, there might be full customization options again based on html/css/js (thanks to nwah1 for pointing that out).
Nadya 11y ago
"To make sure that some of our users are more secure, we're going to implement a change that will cause some of our users to refuse to update their browser - potentially making them less secure." I've disabled updates in FF. Palemoon removed Tab Groups and the addon is extremely buggy and doesn't restore properly when the browser crashes. Waterfox had several issues with plugins I use. I guess it's time to fork FF and maintain my own version, implementing security patches as they come in?
- catern 11y ago
  >I guess it's time to fork FF and maintain my own version, implementing security patches as they come in? AKA Iceweasel?
  - Nadya 11y ago
    Is Iceweasel able to be compiled on Windows? I don't see why they would distribute/maintain it outside of Debian/*Nix distribution. Although maybe they decided not to touch the makefile? (And any currently available "Iceweasel for Windows" is hosted on malware sites.) GNU IceCat could also be an alternative along the same lines, and I know for sure that IceCat can be compiled on Windows and they distribute a Windows binary. The only problem being GNU IceCat doesn't seem to work on my work computer..
    - catern 11y ago
      I have no idea, but I'd guess not, sorry. But if you want to have control over what your computer does, why are you using Windows? :P
      - Nadya 11y ago
        I want control over what my browser does, not necessarily my operating system. I'm highly selective over my software as I require it to fulfill very precise goals in the exact manner of my choosing. If it fails to do so, I'll find better software. For example, I have yet to find an image viewing software that is satisfactory for my usage that exists for Unix distribution. I use an extremely niche, unheard of software that is 'Windows Only'. It's so niche that searching for the name of this software on Google only results in posts of me talking about the software. (I decline to name for privacy reasons.) My operating system is a platform to run software. I'd hop to Debian or Arch in seconds if I could find existing software that meets my needs. While the image browser is one example, there are more that do not exist to my desired standards outside of Windows applications. My desire for software that performs certain functions and in the manner I want outweighs my desire for privacy from my government and control over every system of my operating system. ps: I know your question was probably meant rhetorically.
_wmd 11y ago
As a decade+ Firefox user I think this is fabulous news, not because it'll be easier for Chrome exts to come to Firefox, but because the old extension 'API' was a heap of junk and made it trivial for third parties to really gum up Firefox internals. Also huge kudos to Mozilla for not bikeshedding some new/slightly incompatible API, which I'm not sure Google would have been capable of. :) Chrome's API is much better designed, I suppose, because they had the first chance in 15 years to actually sit down and design a modern/safe API for this specific purpose. XPCOM just exposed JS to endless unsafe internal Firefox interfaces.
- adamc 11y ago
  Chrome doesn't have nearly as many useful plugins. If Firefox ends up that way, I'll probably use something else...
shinratdr 11y ago
Long time coming, the FF extensions system has been a security risk and a development burden for years. Yes, it offered unique advantages, at a significant cost though. Judging by the number of users on Chrome, it's hardly a dealbreaker change for most. Signing & locking down extensions is a necessity. Anyone who has to deal with the user side of IT will attest to that. You can't bury your head in the sand and expect the problem to go away or wipe your hands of it and insist users should know better. The fact of the matter is, browser extensions are one of the most common malware attack vectors nowadays and vendors should be concerned about that. It's going to be an unpopular change amongst hard-core Firefox users and FF-only extension developers, but you can't let diehards force you to drown with the ship. They'll live and find a way. It's regular users who will happily jump ship to Chrome, Edge and Safari without a second thought.
- nightpool 11y ago
  Chrome doesn't sign extensions though, and getting them listed isn't anything more specific then a 5$ charge—how can you judge whether its "hardly a dealbreaking change" based on that?
  - shinratdr 11y ago
    Chrome has moved quite steadily towards only installing extensions listed in the Chrome Web Store, which results in roughly the same restriction. http://blog.chromium.org/2015/05/continuing-to-protect-chrome-users-from.html http://blog.chromium.org/2015/05/continuing-to-protect-chrom... Each vendor is moving at their own pace and in their own way, but the endgame is clear. With that comment, I was also referring to the depreciation of XUL more than the signing requirement.
    - nightpool 11y ago
      No, its absolutely not. The new firefox addon signing requirements are a hundred percent more restrictive then the requirements to get listed on the chrome store.
neves 11y ago
I loved this: " We would like add-on development to be more like Web development: the same code should run in multiple browsers according to behavior set by standards, with comprehensive documentation available from multiple "
Illniyar 11y ago
Frankly the only reason I keep using Firefox instead of Chrome is because of TreestyleTabs. If this change means TreestyleTabs will not work/won't get updated, then I don't see myself continuing to use it.
Tobu 11y ago
Great news. With the current system, firefox's stability, upgrade compatibility and performance were entirely dependent on every author of every extension I use being sufficiently careful. It meant a lot of periodic purges, housekeeping, and reduced trust. I'm sure the overhead helped users move to chrome, despite Firefox's vanilla install being lighter. Reducing the API surface was a necessity. Also, it takes a lot of effort to cope with the churn in internal APIs, and I had to get rid of promising extensions like Pentadactyl because they broke too often. With a smaller, stable API, that problem doesn't exist. I don't believe that the current tradeoff of power vs responsibility was working out in the majority of cases, and I've seen enough evidence in the form of lagging addons and neglected ports.
- the8472 11y ago
  > It meant a lot of periodic purges, housekeeping, and reduced trust. > I don't believe that the current tradeoff of power vs responsibility was working out in the majority of cases, For me those tradeoffs are worth it. Sometimes it means installing a beta builds of an addon or nagging its developer on github or even finding a replacement. But that's still better than not having the addons at all because the APIs simply make it impossible to have them in the first place. If mozilla separated addons into "uses stable APIs only" and "might break at any time, we may even turn them off if they cause to many crashes" that might allow users to choose which kind of model they want to follow.
  - Tobu 11y ago
    XPCOM has support for stable, versioned APIs, but no one cared about using that subset since the rest was also available; it stagnated and the supposedly unstable APIs ended up bearing the compatibility burden. Now there will only be a supported subset, and the trickier stuff will require getting a patch accepted instead of monkey-patching and letting the user cope with the breakage. Your coping skills are above average, I've submitted patches too, it's still yak shaving and not a very productive use of time. Working out APIs is a hard problem, it should be handled as part of the development phase instead of being completely disconnected.
serve_yay 11y ago
> ... [cross-process object wrappers] are much slower than the equivalent DOM operations in single-process Firefox, and can affect the user experience negatively. Also, some accesses aren’t supported by the compatibility layer and will throw exceptions. Hmm, that sounds... bad?
- quotemstr 11y ago
  I don't see why cross-process XPCOM would have to be particularly slow. Windows is built on cross-process COM.
  - TazeTSchnitzel 11y ago
    Windows isn't built on COM, Windows is built on Win32 which is a 1980s API hurriedly updated to 32-bit.
pekk 11y ago
It's only surprising if you don't understand that Mozilla's core mission now is to promote a permanent JavaScript monopoly. Mozilla has committed to blocking any technology which could ever offer equal support to any other languages. Now they cannot even allow plugins unless they are based on JavaScript. "The Web" used to mean web pages and HTTP, now "The Open Web" and "Web Technologies" mean we are forced to work with a growing mountain of ill-considered, weird and unsafe "bad parts" forever. In a strikingly similar parallel dimension, vendors have applied pressure to ensure that networked PCs would only run COBOL, and other languages could only be supported by compiling to a subset of COBOL that inherited its semantics so that nothing would ever be faster than COBOL. In that parallel dimension, this restriction is known as "Open Web", although nobody knows what is open about it.
- skybrian 11y ago
  It sounds like you might not like JavaScript. You should know that there are good languages that compile to JavaScript.
  - pekk 11y ago
    They have the same basic semantics as JavaScript. It's not about that. Even if I liked COBOL, I wouldn't want a world where only COBOL can be used. And it doesn't make sense that this world has to be artificially enforced when there is demand for variety.
    - skybrian 11y ago
      Not sure what you mean by the "same basic semantics". I think the semantics of Go and Elm are quite far away from JavaScript. Dart less so, but it's enough to change the developer experience quite a bit. I don't particularly like x86 instructions, but they also don't bother me that often. Granted that JavaScript isn't sufficiently hidden yet, particularly in debuggers. That will take a few years. On the other hand, it's significantly more readable than assembly and getting better, so as a compiler target language, I think it will work out okay. The forces here are no more artificial than the ones that made the industry standardize on x86 and (later) ARM. Popular, accepted standards become more popular when the barriers to alternatives are very high, as can be shown by the people who tried and failed with strong alternatives.
reitanqild 11y ago
We can talk about "only approved extensions" after they have taken time to consider the pinboard extension. For now I am happy someone have told me that Pale Moon exist.
jimmaswell 11y ago
"This post really marks the final end of Firefox. The end of a truly robust Add-On model is the only thing remaining at all that sets Firefox apart. The Foundation’s constant running after being a Chrome-alike has finally run the browser into the ground fully." This comment hit the nail on the head. Really in general the browser vendors are all killing the web day by day. Maybe ~2004 to around 2013/2014 or so will be remembered as the golden age of web browsers. NPAPI worked in major browsers, you were allowed to install extensions without Mozilla or Google's permission, and Firefox had yet to mutilate its interface in an attempt to be a Chrome lookalike.
Animats 11y ago
"A major challenge we face is that many Firefox add-ons cannot possibly be built using either WebExtensions or the SDK as they currently exist." That's so Mozilla. There's a long history in add-on development of Mozilla deprecating the old thing before the new thing works. XUL/XPCOM had to go. The mobile browser, "Fennec", doesn't use it at all. But the "Jetpack" API, the one Mozilla wanted everyone to use instead of XUL/XPCOM, is apparently being deprecated as well. The announcement says it will "continue to work", but the new API seems to be completely separate from Jetpack. That probably means bugs in Jetpack won't be fixed, and bug reports will be answered with "convert to (new thing)". Mozilla AMO. Embrace the pain.
- toyg 11y ago
  Jetpack was such a clusterfuck. Horribly documented, released while not ready for prime time, missing basic functionality, and progressing as slowly as Italian criminal trials. I can see the point of them starting from scratch. It would have been nice if they had learnt their lesson and actually started communicating changes after they had something real to show, but alas, it seems like they're doing the same thing, just a little bit faster (maybe).
  - Animats 11y ago
    "Jetpack was such a clusterfuck." Yes, and now that it pretty much works, after years of bug reports and nagging to get bugs fixed, they're deprecating it.
toyg 11y ago
It looks like a bad case of Big Rewrite. Which is mildly unsurprising, coming from an organization that was created to undertake a Big Rewrite; however, after the dismal Jetpack experience, I'm surprised they want to do it all over again, just harder and with no safety net. How can you tell your own developer community "what you're doing now, it won't be allowed next year; but what will be, we don't know yet"? You might as well tell them to go home.
thiht 11y ago
>We have decided on an approximate timeline for the deprecation of XPCOM Thank god, this undocumented crap is a nightmare to use
jaredsohn 11y ago
>Blink-compatible API in Firefox called WebExtensions Does anyone know why they are calling this API Blink-compatible rather than Chromium-compatible? My understanding is that Blink is just the rendering engine and extension code can be found within the main Chromium project. My best guess is that they are referring to it this way since I think that currently the list of browsers that use Blink is the same as the list of browsers that use Chromium code and people are more used to categorizing browsers based on their rendering engine rather than where the code originated.
- dragonwriter 11y ago
  > Does anyone know why they are calling this API Blink-compatible rather than Chromium-compatible? That's a good question, since the two sources they link to (from Chrome and Opera) both refer, directly or indirectly, to Chromium extensions, and neither refers to "Blink" at all.
ajnin 11y ago
We all know too well what happens when a backwards-breaking change is imposed without strong functional justifications : most developers don't actually put the effort to upgrade and as a result the vast majority of extensions break. Case in point : python modules, after tremendous effort and years of waiting about 2/3rd of the existing modules have been ported from python 2 to 3. This is relatively "mitigated" in the case of add-ons because backwards-incompatibility has become the norm so old add-ons are likely to break anyway at some point, but this still seems like a very bad idea for Mozilla to kill a large portion of their ecosystem in that single move, especially if in the bunch are very differentiating extensions like Tree Style Tabs. Justifying the decision by becoming even more interchangeable with Chrome is especially baffling, what is the strategic point of this?
- TazeTSchnitzel 11y ago
  Python 2/3 yielded very little benefit. That's not the case for Firefox's migration: WebExtensions are easier to write and work with other browsers.
Aardwolf 11y ago
Well, that might make me look into SeaMonkey again...
mindcrime 11y ago
Ya know, my initial reaction to this was pretty negative. As a developer, I don't like the idea of losing access to a more powerful technique in favor of a less powerful one. If I want to write an add-on, I want XPCOM / XUL, etc., at least as an option. However, giving it more thought, I think this might actually be a Good Thing in the long-run. OK, it's a stretch, but hear me out... I've been a vocal opponent of this whole idea of making the browser a poor man's operating system for a while. I want a Web where browsers are really good at, well, browsing hypermedia, and other applications handle "application stuff". So maybe, in a roundabout fashion, making it a little bit harder to extend the browser even further, will encourage people to shift back to a model of handing off some kinds of requests to an entirely different app, rather than trying to shoe-horn the kitchen sink, bathtub, 3d printer, milling machine, jumper cables, semiautomatic pistol, bandsaw, swimming pool, and clown suit all into the browser. Or maybe not. Hey, a guy can wish, right?
- dragonwriter 11y ago
  I think the opposite is more likely: Firefox and Chrome using the same extension mechanism -- and, inevitably, that means two-way chasing on implementing APIs that prove useful -- means that even if the ability to do more complex apps in Firefox falls in the short run, the ability to more complex apps in the browser in general (or, at least, Firefox, Chrome, and their descendants and others who adopt the same framewoek) is going to accelerate over a longer term.
  - mindcrime 11y ago
    Yeah, I'm afraid you're right. :-( But like I said, a guy can wish. A more interesting question might be: "What would it take to slow down this movement towards doing everything (and then some) IN the browser"?
e12e 11y ago
Uh-oh. The main reason I use firefox is vimperator. Followed by the open source, easy to self-host sync framework, noscript and adblock. One thing I don't see anything about wrt extensions is user control. If ff is to remain relevant - signing extensions will need to come with a trust management framework. I might want to run extensions signed by Debian and myself - but not mozilla (in iceweasel). RedHat (or other vendor) might want their unbranded ff fork to only use RedHat extstensions by default; maybe with an option to also allow upstream ff signed exstensions. Without that; I see no point in signing support in a free software product?
- hackuser 11y ago
  Regarding Vimperator: https://billmccloskey.wordpress.com/2015/08/21/firefox-add-on-changes/ https://billmccloskey.wordpress.com/2015/08/21/firefox-add-o...
  - e12e 11y ago
    Well, that's more regarding Noscript and Tree Style Tabs, actually -- it only mentions vimperator/pentadactyl in passing. Either way, thank you for the link -- hopefully the development of new APIs won't lead to a regression wrt. the add-on ecosystem :-)

281 points by zawaideh 11y ago

shock 11y ago

> The Beta and Release versions of Firefox based on 42 and above (Beta 42 will be released at the same time as Firefox 41) will remove the preference that allows unsigned extensions to be installed, and will disable and/or prevent the installation of unsigned extensions. This is very bad news for me. I'm a power user that prefers the balance of new features/chance of breakage that the Beta channel offers and I take full responsibility for the addons I install and the security decisions I make. I don't need Mozilla to be "defending" me in this case.

zawaideh 11y ago
Fully agree. On Mac OS X you can still run unsigned apps, but you have to be savvy enough to do so. Mozilla should at the very least adopt such an approach.
- geekingfrog 11y ago
  xpinstall.signatures.required should be the setting you're looking for.
  - super_mario 11y ago
    This option will be removed from about:config in Firefox 42.
  - shock 11y ago
    That's the option I'm currently using and that Mozilla plans to remove in Firefox 42.
    - CmdrKrool 11y ago
      Could someone make an extension to re-enable this config option? And... would Mozilla agree to sign it? (Since, you know, the standard response over the years to users complaining about removed functionality in Firefox has been, "use an extension")
      - shock 11y ago
        I doubt an extension could do that since the signing mechanism needs to be secure, otherwise it would be pointless.
      - nightpool 11y ago
        no, because then any malware would immediately install that extension first, and then flip the about:config bit on the filesystem, and then install their extension, and then you're right back where you were before signing.
- ianbicking 11y ago
  A big problem for a lot of Firefox users is addons that are side-loaded into a profile. Like when you download some junk and it comes with an installer that injects an addon into your profile. This is a good expose on what even a seemingly legitimate site like download.com does: http://www.howtogeek.com/198622/heres-what-happens-when-you-install-the-top-10-download.com-apps/ http://www.howtogeek.com/198622/heres-what-happens-when-you-... (and several of the malware examples in that article are side-loaded addons). Unfortunately hoops aren't enough to fix this problem, because hoops generally involve some flag that you've gone through the hoop, and the installer can easily fake that.
  - ptx 11y ago
    Couldn't those installers patch Firefox to remove the signing requirement? Or, if they don't get sufficient privileges to modify the executable, patch the user's Firefox process in memory?
    - Tobu 11y ago
      Chrome did a similar change which led to a pretty spectacular drop: http://blog.chromium.org/2015/05/continuing-to-protect-chrome-users-from.html http://blog.chromium.org/2015/05/continuing-to-protect-chrom...
    - ianbicking 11y ago
      Yeah, this might end up being just a salvo in a longer battle. But maybe part of the problem is that some of these malware authors are lying to themselves and believe they are just grayhat hackers, and once you start patching executables it becomes a bit clearer you are a blackhat. So far download.com isn't distributing actual rootkits. They could of course. And yet still they probably won't. Relatedly I did notice when putting my own addon through the signing process that there was a checkbox specifically for sideloaded addons, with the implication that the checks would be even more stringent. I'm not sure if that's enforced or not, or how.
  - deno 11y ago
    How is that Mozilla’s problem? If you close all the “hoops” the rogue installer can just simply replace Firefox with its own build of “Firefox.” I truly don’t understand why Mozilla is trying to do Microsoft’s job.
sonnyp 11y ago
Use Firefox Beta or Firefox Nightly
- shock 11y ago
  I'm already using Firefox Beta. I don't want to be using Firefox Nightly.
  - brighteyes 11y ago
    As others said elsewhere, mozilla will provide builds of Beta that do not have this issue. It's just that the default build will.
- sandyarmstrong 11y ago
  The preference is being removed from Beta, as quoted above. Nightly is just not a great answer for a "power user".
- gcb0 11y ago
  but i actually do work. I'm not testing new ff releases all the time. i also run Aurora for that. now you say release/sign your extensions.... well they mostly contain internal data and URLs. no way I'm publishing any of those.
  - nightpool 11y ago
    You don't need to publish extensions to get them signed, AMO will sign unlisted extensions that are submitted. this doesn't really change the situation for enterprise users though.
    - detaro 11y ago
      Allow enterprise users to generate firefox executables with additional trusted certificates and distribute that on their machines instead of the original?
nine_k 11y ago
«The Nightly and Developer Editions of Firefox based on 42 and above will retain the preference to disable signing enforcement, allowing the development and/or use of unsigned add-ons in those versions» So I think running the Developer Edition (which I expect to be much more stable than Nightly) is probably your best bet.
- shock 11y ago
  The thing is, I'm not a web developer and I don't think I should be forced to use the Developer Edition just so I can remain in charge of what I install in my browser. Now that I'm writing this it occurs to me that after this change it's not really my browser anymore, is it?
  - catern 11y ago
    Use Iceweasel or GNU Icecat?
    - shock 11y ago
      Thanks for the suggestion! That's what I'll prolly end up doing although neither of them are in the Ubuntu repos.
  - outworlder 11y ago
    Are you sure you are a 'power user', then?
    - shock 11y ago
      I'm not sure what you mean, but are you suggesting that if I'm a savvy driver I should just drive prototype cars?
      - nightski 11y ago
        Are you suggesting that the developer edition is merely a prototype and not a production browser?
Animats 11y ago
One reason for add-on signing is that there's a major attack on Firefox using stolen add-on IDs to insert malware. This started in early 2015, and one of my add-ons has about one-third bogus versions out there. They all have different random version numbers, typically above 1000. Those are about to get flushed out of the ecosystem. Whether add-on signing is part of a power trip at Mozilla to enforce a walled garden with Mozilla-favorable policies remains to be seen. When Mozilla blocks an add-on which disables Pocket or Sync or Hello, we'll know that AMO has turned to the dark side.
- makomk 11y ago
  That could presumably be solved by allowing developers to sign their own add-ons and tying the ID to the key they used to sign it - it doesn't require a centralised signing system of the kind Mozilla introduced.

superkuh 11y ago

Well, this is all terrible. They mention having to use the nightly or developers releases instead of their walled garden versions. But both of those are unstable and very crashy. And how likely are they to keep the unbranded version up and updated as time goes on? And getting rid of the entire firefox add-ons community is just insane. The add-ons are what makes firefox good. It's why people use Firefox. I guess if they just want us to use Chrome this series of changes will work great.

eli 11y ago
Firefox Developer Edition is for web developers, not for browser developers. It isn't like a nightly -- it's stable. https://www.mozilla.org/en-US/firefox/developer/ https://www.mozilla.org/en-US/firefox/developer/
- superkuh 11y ago
  Have you used it? After I heard about the changes coming down the line in 41 a week or so back I immediately downloaded it and started configuring it to be my new main browser. The only problem was that it crashed constantly. It's just anecdotal but my personal experience backs up what I've said here.
  - the8472 11y ago
    Well, to give a counter-anecdote: I've been using nightly for years and only experience severe problems maybe a handful times per year, the rest of the time it works fine. And that's with several extensions and many tabs.
  - ohkine 11y ago
    FYI, i have used Aurora/DevEdition almost exclusively (outside of testing) on at least a dozen different Windows and OS X machines ever since the Aurora channel was created and i have never once had a serious problem. Occasionally i find little visual glitches or whatever, but it rarely ever crashes and i never get data loss or anything severe like that.
- 11y ago

fweespeech 11y ago

The title is a bit misleading: > We are implementing a new extension API, called WebExtensions—largely compatible with the model used by Chrome and Opera—to make it easier to develop extensions across multiple browsers. This is basically the creation of a new, multi-browser API standard for browser extensions. This isn't them just adopting a single competitor's ecosystem. There is also a slim chance IE and Safari will join the plugin ecosystem. EDIT: Ty mods, this title is more reasonable.

amyjess 11y ago
> There is also a slim chance IE and Safari will join the plugin ecosystem. You mean Edge. IE development is pretty much dead except for maintenance releases, and it now exists solely to handle legacy websites (read: corporate dinosaurs that rely on ActiveX).
- fweespeech 11y ago
  Edge is basically IE in purpose and function. I don't really buy into the rebrand.
makomk 11y ago
Recent releases of Opera are just a reskinned version of Chrome. This is exactly them adopting a single competitor's ecosystem, it's just that Opera did the same thing even more completely a while ago.
superkuh 11y ago
That's true. But that isn't what most users care about regarding this change. Just look at these comment threads: users care about the power-user extensions being forced out. There's a definite drop of support. Firefox is dropping the add-ons that made it special. The title now is just spin.

annoyingdisb 11y ago

WebExtensions is very good news. One of the biggest pains is to develop extensions compatible both with FF and Chrome so it would make our lives a lot easier.

mrbig4545 11y ago

It doesn't mention addon permissions, which I would assume is something WebExtensions has, since that's how addons work in chrome. At least I hope this is the case, lack of permissions in firefox addons is a little scary, and probably one of the reasons I have the minimum addons installed Anyone have more info on this?

snowwolf 11y ago
Same permissions model as Chrome - https://wiki.mozilla.org/WebExtensions#Permission_Model https://wiki.mozilla.org/WebExtensions#Permission_Model
- mrbig4545 11y ago
  Excellent, that's what I wanted to hear! Thanks
Ded7xSEoPKYNsDd 11y ago
I'm much more relaxed using Firefox add-ons from addons.mozilla.org than Chrome extensions because Mozilla has actual people making sure that the add-ons don't do any nefarious things. (Or at least forces them to disclose that properly.) On the other hand, getting hidden adware or password keyloggers into the Chrome store is no problem at all.

tetraodonpuffer 11y ago

I was under the impression that add-ons like ublock / umatrix were possible only in firefox due to its very permissive add-on model, if mozilla is going to deprecate XUL / XPCOM would it mean this kind of add-on won't be possible anymore?

timdafweak 11y ago
That's the first thought that came to my mind as well. Addons like Fire Gestures and Easy Dragtogo are what keep me on Firefox. Chrome can't implement those apparently, and now it seems that support for them will be deprecated too.
snowwolf 11y ago
uBlock - https://chrome.google.com/webstore/detail/ublock-origin/cjpalhdlnbpafiamejdnhcphjbkeiagm https://chrome.google.com/webstore/detail/ublock-origin/cjpa... uMatrix - https://chrome.google.com/webstore/detail/umatrix/ogfcmafjalglgifnmanfmnieipoejdcf https://chrome.google.com/webstore/detail/umatrix/ogfcmafjal...
- tetraodonpuffer 11y ago
  thanks for the clarification, I haven't looked at add-ons for other browsers for quite a while, and at the time I remember discussions about adblock not being possible to be done anywhere else like in FF due to the add-on model, glad to see this does not seem to be the case anymore
  - falcolas 11y ago
    I think the big difference is being able to pre-emptively block/modify requests, vs. changing what is displayed after the fact.
    - tetraodonpuffer 11y ago
      that was what I thought as well, however I went to the umatrix github page and if you look at the top it links this page[1] that discusses how umatrix needs permission to disable prefetching so no network connections are made for blocked sites, which seems to imply it can do the pre-emptive blocking as opposed to just hiding of elements. I am wondering though now if I am mixing things up in my brain and the issues were with safari add-ons as opposed to chrome/chromium: there is no umatrix for safari[2] that I can see, ublock seems available but not ublock origin, but I am not sure if ublock on safari just hides or actually pre-emptively blocks. [1] https://github.com/gorhill/uMatrix/releases/tag/0.9.1.2 https://github.com/gorhill/uMatrix/releases/tag/0.9.1.2 [2] https://github.com/gorhill/uMatrix/issues/96 https://github.com/gorhill/uMatrix/issues/96

deleted 11y ago

[deleted]

kibwen 11y ago

Standardizing the basic means of browser extension is something that I've been eagerly awaiting ever since Microsoft announced that Edge will support both Firefox (Jetpack) extensions and Chrome extensions. But how will future versions of Firefox handle the extensions that just can't exist in Chrome, such as NoScript and Tree Style Tabs? EDIT: I'm also excited at the idea that this could give Servo a running start at an extensions story, since Servo will never in a million years support XUL or XPCOM and hence all non-Jetpack Firefox addons are destined to fail there anyway.

micro-ram 11y ago
I use ScriptSafe (formerly ScriptNo) in Chrome similar to NoScript on Firefox. Also check out uMatrix. https://code.google.com/p/scriptno/ https://code.google.com/p/scriptno/
- jb613 11y ago
  For one, it only a subset of Noscript: "A simple extension that brings SOME OF NoScript's functionality to Chrome" Secondly, in order to achieve its goal, it's relying on a hack: ... if (getElSrc(this) && getElSrc(this).toLowerCase().substr(0,11) != 'javascript:' && getElSrc(this).toLowerCase().substr(0,17) != 'chrome-extension:') ... Not taking anything away from this extension, just that this illustrates what everyone's saying - concerns about reduced functionality.

deleted 11y ago

[deleted]

nocman 11y ago

"we will require all extensions to be validated and signed by Mozilla starting in Firefox 41" I hope there is an "opt out" option to this for people who know what they are doing. I understand the reasoning behind it, but what about an extension I write just for myself that I don't wish to share with Mozilla? I don't particularly like having that option taken from me. Yeah, I know, I could edit the source and work around it -- but based on past attempts to just build firefox, that could be a real pain.

the8472 11y ago
There will be unbranded builds that provide that option, branded builds will enforce signature verification.
- nocman 11y ago
  Are you referring to iceweasel? Or are you referring to an unbranded build provided by Mozilla? I honestly don't remember any other browsers that have the Mozilla branding removed, but I haven't really tried to find any.
  - lol768 11y ago
    Mozilla will provide these unbranded builds in the en-US locale. See "What are my options if I want to install unsigned extensions in Firefox?" in the FAQ for more info: https://wiki.mozilla.org/Addons/Extension_Signing#FAQ https://wiki.mozilla.org/Addons/Extension_Signing#FAQ

antman 11y ago

The last Symbian in Nokia phones was also very strict with signed applications. I bypassed it, but it is my impression that most people did't bother.

shwetank 11y ago

We at Opera have called on for a single (or at leat a shared) API for making browser extensions, which I think will benefit the developer community immensely (instead of making one set for each browser). I think now the time is right to take a look again at NEX https://dev.opera.com/blog/introducing-nex/ https://dev.opera.com/blog/introducing-nex/ and standardising core parts of browser extensions.

super_mario 11y ago

And this is how Google killed Firefox. Why do people use Firefox? For extensions. What breaks extensions, frequent updates and extension API changes. Google managed to suck Mozilla into frequent releases and now extension API changes that make Firefox yet another generic easy to substitute browser. Wow, just wow.

uxcn 11y ago
Frequent releases aren't a bad thing, per se. Although, huge API changes like this, without a valid plan for supporting existing ones a large community depends on seems like a disaster in the making. The impression I get is that Mozilla wants to be more involved in the user experience around their codebase, but personally I preferred firefox's lack of involvement. I think the UI is poorly designed and getting worse, but as long as it was easy to modify, it wasn't an issue. The real value in firefox for me is gecko. Most other things largely get in the way, and it seems like that's what's becoming the focus. I can understand the need for a better designed add-on API, but there should probably be a non-compulsory reason for people to switch.
MichaelGG 11y ago
I use Firefox because it's open and more pro-user than Google is. And Mozilla's work on Rust is incredibly important too. (Rust manages to accomplish what decades of effort and loads of money on C analyzers and mitigation techniques fail to.) So it's important, ethically, to support Firefox.

jpatel3 11y ago

There used to be a time when I loved firefox..the new versions are slow and sluggish. If I open the developer console, its super slow.

Tobu 11y ago
The developer console can disable the cache so that you can edit websites live, is that what you're seeing? Also, I wonder if it's still slow if you restart with extensions disabled. There's a lot of hidden interactions in the current model.

amyjess 11y ago

I'm really disappointed with them deprecating XUL extensions. I use a number of extensions that extensively modify the UI (e.g. Tab Mix Plus), and honestly I'd rather just stick with an older version of Firefox than use Firefox without these extensions.

Tobu 11y ago
They're using the WebExtension model of isolated extensions with permissions. They're not going to limit themselves to any competitor's API, they'll build a superset by consulting with the developers of popular extensions. Tab Mix Plus being the 15th most popular extension, it's pretty certain they'll be consulted on the new APIs. Quoting from the announcement: > A major challenge we face is that many Firefox add-ons cannot possibly be built using either WebExtensions or the SDK as they currently exist. Over the coming year, we will seek feedback from the development community, and will continue to develop and extend the WebExtension API to support as much of the functionality needed by the most popular Firefox extensions as possible.

keypusher 11y ago

Disabling unsigned extensions without any opt-in is a terrible decision. Putting up barriers to entry for addon developers in a browser that survives primarily based on the addon ecosystem is suicidal. Addon developers do not want to run unstable alpha channel builds, they don't want to have to manage multiple profiles, they don't want to build Firefox from scratch because the version they need is not available via a package manager. I really don't care about the rest of these changes, but they need to rethink their stance on unsigned extensions.

nocman 11y ago
I agree. One possible workaround would be to provide a way to add keys from which you would accept extensions. Then as part of the extension development process, you could sign your extension with your key when you are ready to install it. If the issue Mozilla is really concerned about is security, this should be an acceptable solution.
- coldpie 11y ago
  I think you have a good idea, but > If the issue Mozilla is really concerned about is security, this should be an acceptable solution. I don't know what you're implying here. That they're not concerned about security? What are they concerned about?
  - nocman 11y ago
    No, indeed I do hope that security is the primary thing they are concerned about. But it is possible they have other motivations (like control). I hope that is not the case, but I think it would be foolish to not even consider the possibility.
- TazeTSchnitzel 11y ago
  > One possible workaround would be to provide a way to add keys from which you would accept extensions. Then malicious apps will just sideload new keys.
11y ago

jasonhansel 11y ago

I switched to Firefox in part because XUL-based extensions can heavily customize the user interface. Things like Tile Tabs, Tab Mix Plus, and other extensions have been extremely useful to me. Despite my dislike of XUL as a language, I'm sad to see XUL extensions go; I suspect that WebExtensions will, like Google Chrome extensions, be much more limited. In fact, I had always hoped that FF would move in the opposite direction, and split itself apart into a bundle of extensions, so that even more customization could be possible. I've also always enjoyed being able to run the latest versions of extensions, which sometimes take a while to get Mozilla's approval. Are there any plans to maintain a fork of Firefox that will not include these changes?

jasonhansel 11y ago
In short, I would like to find a web browser that follows the Unix philosophy to a greater extent than Firefox/Chrome/IE.
- amk_ 11y ago
  Vivaldi? Midori?
  - jasonhansel 11y ago
    IIRC, Vivaldi uses Chrome extensions, which have the same limitations as the new Firefox WebExtensions. Not sure about Midori.
- catern 11y ago
  I don't really know why, but I have some small optimism that Servo might enable such a browser. The only other candidate browser engine is Webkit, which is already too huge to be part of a small Unixy browser. Maybe Servo, as a project that people are actively hacking on, might work. Alternatively, maybe https://github.com/breach/breach_core https://github.com/breach/breach_core though their website is down, so maybe the project is dead...
  - 11y ago

tenfingers 11y ago

You know, I had plenty of reasons to list about how useless signed extensions are for what they're trying to achieve... I'm even _already_ running an "unbranded" firefox in all my devices (iceweasel, fennec), for the same reasons I have to run chromium, so I won't even be _directly_ affected.... But there's only one thing I really want to say to Mozilla right now, as a developer: Fuck you Mozilla. And there's another, as an user of which most extensions are unsigned: Fuck you again, Mozilla. aaah feels better.

jimmaswell 11y ago
I agree, the web gets less and less open and free by the minute. It's actively hostile to user choice half the time.
- tenfingers 11y ago
  When Mozilla will decide, apple/google style, what is and what is not acceptable as an extension for their browser, people will maybe realize that this is just the tipping point. But maybe that won't be necessary anyway. By adopting a very limiting standard for extension development and dropping xul (which might be a good idea for other reasons though), there won't be any significant difference between firefox and (say) chrome. A few tweaks in the browser frame won't attract masses of people. Switching from Chrome to Firefox on Android require a pretty big incentive. Right now, I'm on firefox only for the extensions. I have really no other compelling reasons.

fra 11y ago

I worry that extensions that implement their own navigation and user experience will no longer be possible. I use Vimperator extensively and would hate to see it go. Chrome does have Vimium, but it is quite clunky and limited compared to the couple of Firefox solutions.

__david__ 11y ago

So on the one hand I love that they're moving forward. Sometimes it's good to get rid of cruft (and boy is XPCOM crufty). On the other hand, the rich extension ecosystem is one of the highlights of Firefox. I honestly don't know what I'll do if my TreeStyleTab extension is disabled. I lucked out because the Beta version has the preference to use unsigned extensions. But that extension is so fundamental to my Firefox experience that if they remove that preference in the new version then I think I'll have no choice but to turn off updates and live with my current version indefinitely. And that doesn't make me happy.

jasonhansel 11y ago
Furthermore, I doubt that such extensions will work without XUL/XPCOM, at least if WebExtensions work like Chrome extensions.
- nwah1 11y ago
  That's why they're also working on browser.html so vigorously https://github.com/mozilla/browser.html https://github.com/mozilla/browser.html Web standards are fully capable of rendering entire user interfaces now. GUI toolkits are just needless dependencies for web rendering engines.
  - fabrice_d 11y ago
    Exactly. Once all your front-end is in html, including the part that manages tabs, nothing prevent a WebExtension to implement TreeStyleTabs. Also note that the same extension support is landing in Firefox OS (we are working on the missing apis), and will let you install the same extensions everywhere. I understand people mourning xpcom access. You can do fun things with that, but I've also seen my share of horrors when I was reviewing add-ons (let's override the http protocol handler, what could go wrong!).
    - wldcordeiro 11y ago
      Except for people losing interest in developing for the platform due to all the API churn. By the time all this lands no one will care to implement TreeStyleTabs.

dannysu 11y ago

I still don't like that the AMO review process can take weeks and months. Mozilla even says it themselves! But hopefully with WebExtension and a permission model things will get easier for getting through reviews.

simonster 11y ago

It used to be that Firefox extensions could have the same capabilities as Firefox itself. It seems that this move is relegating them to second-class status. Here's a list of things missing from the Chrome/WebExtensions API that our extension currently does: - Customization of the browser UI beyond a single, simple toolbar button or a few other specially implemented widgets. - Reading/writing arbitrary files to the file system. There is chrome.fileSystem, but it's limited in what it allows, and it isn't available to extensions, only Chrome apps. - Interfacing with other applications. This typically requires using platform-native APIs, which was possible with js-ctypes (https://developer.mozilla.org/en-US/docs/Mozilla/js-ctypes https://developer.mozilla.org/en-US/docs/Mozilla/js-ctypes). Chrome has a socket API, but it's not really the best way to do IPC, and it isn't available to extensions anyway. - Some kind of SQL database. Firefox has an SQLite interface (MozStorage), but it's not part of the WebExtensions API. Chrome actually has WebSQL, but Firefox never implemented that (with good reason, IMO; it's tied to a SQLite and shouldn't be used on the web). I guess you'd better like IndexedDB. - Native-looking UI widgets. This is certainly possible to do in HTML, but it's not always so easy. For example, we have yet to find any reasonable HTML-based replacement for our tree view that's both visually appealing on all platforms and reasonably performant with thousands of items. (If you have suggestions, let us know!) I guess Mozilla's viewpoint is that, since everyone is already supporting Chrome, they don't need these things. However, for our extension, the difference between the Chrome and Firefox implementations is that the Chrome implementation needs to talk to a separate app, while the Firefox implementation can do everything itself. Firefox used to give us a very powerful toolkit for writing apps, the same toolkit they used to create Firefox. Now it looks like all we'll have is a toolkit for writing simple browser extensions. I think many people use Firefox because they can customize it the way they want to. Soon you won't be able to customize Firefox any more than Chrome. Maybe Mozilla is banking on Servo being so fast/secure that people will use it over Chrome even when all the other advantages are gone.

deleted 11y ago
[deleted]
spaceribs 11y ago
The customization element was nice, but I feel like most of these issues will be addressed by future developments. With everyone using close to the same API, we have to move backward a bit, but one browser implementing a feature like file access means developers going to other browsers and saying "Why can't I do the same thing from the other guy?" While this somewhat exists already, it will be much louder if they aren't entirely different plugin architectures and used as a developer excuse.

scottjad 11y ago

A funny comment on the post: "BTW, if you really want to show us that you trust this much in these new WebExtensions, the first ones to appear at AMO should be Pocket and Hello. Remove that code from the core Firefox and put it where it always should have been: an extension that anyone interested can easily install." And a more serious comment from a developer of DownThemAll!: "I was thinking of abandoning add-on development for a while now, mostly because of the Walled Garden signing approach that went live, which I strongly objected to and still strongly object to… I might have come to terms with it, once I see it play out in an actual implemention… But “deprecating” XUL-based add-ons with XPCOM access takes the cake. Once that happens, I will abandon ship for sure. Simply because I cannot continue developing most add-ons at all as they will not and cannot fit into any “WebExtensions” API. The flexibility of what XUL-based add-ons can do IS the major selling point of the Firefox add-ons ecosystem and therefore IS one of the last remaining selling points of Firefox itself that isn’t purely ideological. In comparison, the APIs that Chrome and competitors offer, that the Firefox Jetpack/ Add-on SDK offers, are just… toys. To give a little background about myself to show that I’m not just the random hater shooting a drive-by comment: I wrote some more or less successful add-ons in the past, including DownThemAll!, and reviewed many, many add-ons as an AMO volunteer." https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/comment-page-1/#comment-218580 https://blog.mozilla.org/addons/2015/08/21/the-future-of-dev...

dafrankenstein2 11y ago
or if firefox wants to keep it in the core, they should maintain high attention on Pocket( ensuring there is no security flow)
wvenable 11y ago
I use Tab Mix Plus for multi-row tabs in Firefox. It's so important to how I browse that it's the main reason why I use Firefox. If it goes away, then I have no reason to use Firefox.
- thom_nic 11y ago
  I was thinking the same thing. Tab Mix Plus sounds like one of those extensions that might not be doable under the new API... Which would explain why there's no chrome version. Also the main reason why I use Firefox as well... This window has 20 tabs open :)

dafrankenstein2 11y ago

though its late, security review is a great thing! (maybe firefox realized its urgency after a major security flow found in Pocket.)

scottjad 11y ago

They want to kill XUL for Firefox, so they must first kill XUL for add-ons so that the add-on situation sucks so bad with XUL Firefox that people don't lose anything by moving to non-XUL Firefox. And once they kill XUL, they can kill gecko, the maintenance of which is the bane of their job.

holygoat 11y ago
That's not the plan. We've identified that XUL is a growing impediment to Firefox's continued success. Exactly what that means (there are dozens of reasons and dozens of ways forward), and how we're going to tackle it, is a big topic that we're digging into. Yes, removing XUL implies that XUL-based add-ons are not going to last forever. That doesn't mean there won't be a path from here to there: everyone involved recognizes that add-ons are important, and we're increasingly going to be shipping parts of Firefox itself using add-on mechanisms. And I haven't seen anyone seriously consider killing Gecko: it continues to be awesome, and one of the motivations for deXULification is to allow our platform developers the freedom to only focus on supporting HTML UIs, not a mix of HTML and XUL.

slasaus 11y ago

"A major challenge we face is that many Firefox add-ons cannot possibly be built using either WebExtensions or the SDK as they currently exist. Over the coming year, we will seek feedback from the development community, and will continue to develop and extend the WebExtension API to support as much of the functionality needed by the most popular Firefox extensions as possible." So to all extension developers leaning on the current permissive features or XUL/XPCOM, please contact Mozilla and help them with finalizing their WebExtension API in the upcoming year. Also, in the future if all XUL in Firefox is replaced by browser.html, there might be full customization options again based on html/css/js (thanks to nwah1 for pointing that out).

Nadya 11y ago

"To make sure that some of our users are more secure, we're going to implement a change that will cause some of our users to refuse to update their browser - potentially making them less secure." I've disabled updates in FF. Palemoon removed Tab Groups and the addon is extremely buggy and doesn't restore properly when the browser crashes. Waterfox had several issues with plugins I use. I guess it's time to fork FF and maintain my own version, implementing security patches as they come in?

catern 11y ago
>I guess it's time to fork FF and maintain my own version, implementing security patches as they come in? AKA Iceweasel?
- Nadya 11y ago
  Is Iceweasel able to be compiled on Windows? I don't see why they would distribute/maintain it outside of Debian/*Nix distribution. Although maybe they decided not to touch the makefile? (And any currently available "Iceweasel for Windows" is hosted on malware sites.) GNU IceCat could also be an alternative along the same lines, and I know for sure that IceCat can be compiled on Windows and they distribute a Windows binary. The only problem being GNU IceCat doesn't seem to work on my work computer..
  - catern 11y ago
    I have no idea, but I'd guess not, sorry. But if you want to have control over what your computer does, why are you using Windows? :P
    - Nadya 11y ago
      I want control over what my browser does, not necessarily my operating system. I'm highly selective over my software as I require it to fulfill very precise goals in the exact manner of my choosing. If it fails to do so, I'll find better software. For example, I have yet to find an image viewing software that is satisfactory for my usage that exists for Unix distribution. I use an extremely niche, unheard of software that is 'Windows Only'. It's so niche that searching for the name of this software on Google only results in posts of me talking about the software. (I decline to name for privacy reasons.) My operating system is a platform to run software. I'd hop to Debian or Arch in seconds if I could find existing software that meets my needs. While the image browser is one example, there are more that do not exist to my desired standards outside of Windows applications. My desire for software that performs certain functions and in the manner I want outweighs my desire for privacy from my government and control over every system of my operating system. ps: I know your question was probably meant rhetorically.

_wmd 11y ago

As a decade+ Firefox user I think this is fabulous news, not because it'll be easier for Chrome exts to come to Firefox, but because the old extension 'API' was a heap of junk and made it trivial for third parties to really gum up Firefox internals. Also huge kudos to Mozilla for not bikeshedding some new/slightly incompatible API, which I'm not sure Google would have been capable of. :) Chrome's API is much better designed, I suppose, because they had the first chance in 15 years to actually sit down and design a modern/safe API for this specific purpose. XPCOM just exposed JS to endless unsafe internal Firefox interfaces.

adamc 11y ago
Chrome doesn't have nearly as many useful plugins. If Firefox ends up that way, I'll probably use something else...

shinratdr 11y ago

Long time coming, the FF extensions system has been a security risk and a development burden for years. Yes, it offered unique advantages, at a significant cost though. Judging by the number of users on Chrome, it's hardly a dealbreaker change for most. Signing & locking down extensions is a necessity. Anyone who has to deal with the user side of IT will attest to that. You can't bury your head in the sand and expect the problem to go away or wipe your hands of it and insist users should know better. The fact of the matter is, browser extensions are one of the most common malware attack vectors nowadays and vendors should be concerned about that. It's going to be an unpopular change amongst hard-core Firefox users and FF-only extension developers, but you can't let diehards force you to drown with the ship. They'll live and find a way. It's regular users who will happily jump ship to Chrome, Edge and Safari without a second thought.

nightpool 11y ago
Chrome doesn't sign extensions though, and getting them listed isn't anything more specific then a 5$ charge—how can you judge whether its "hardly a dealbreaking change" based on that?
- shinratdr 11y ago
  Chrome has moved quite steadily towards only installing extensions listed in the Chrome Web Store, which results in roughly the same restriction. http://blog.chromium.org/2015/05/continuing-to-protect-chrome-users-from.html http://blog.chromium.org/2015/05/continuing-to-protect-chrom... Each vendor is moving at their own pace and in their own way, but the endgame is clear. With that comment, I was also referring to the depreciation of XUL more than the signing requirement.
  - nightpool 11y ago
    No, its absolutely not. The new firefox addon signing requirements are a hundred percent more restrictive then the requirements to get listed on the chrome store.

neves 11y ago

I loved this: " We would like add-on development to be more like Web development: the same code should run in multiple browsers according to behavior set by standards, with comprehensive documentation available from multiple "

Illniyar 11y ago

Frankly the only reason I keep using Firefox instead of Chrome is because of TreestyleTabs. If this change means TreestyleTabs will not work/won't get updated, then I don't see myself continuing to use it.

Tobu 11y ago

Great news. With the current system, firefox's stability, upgrade compatibility and performance were entirely dependent on every author of every extension I use being sufficiently careful. It meant a lot of periodic purges, housekeeping, and reduced trust. I'm sure the overhead helped users move to chrome, despite Firefox's vanilla install being lighter. Reducing the API surface was a necessity. Also, it takes a lot of effort to cope with the churn in internal APIs, and I had to get rid of promising extensions like Pentadactyl because they broke too often. With a smaller, stable API, that problem doesn't exist. I don't believe that the current tradeoff of power vs responsibility was working out in the majority of cases, and I've seen enough evidence in the form of lagging addons and neglected ports.

the8472 11y ago
> It meant a lot of periodic purges, housekeeping, and reduced trust. > I don't believe that the current tradeoff of power vs responsibility was working out in the majority of cases, For me those tradeoffs are worth it. Sometimes it means installing a beta builds of an addon or nagging its developer on github or even finding a replacement. But that's still better than not having the addons at all because the APIs simply make it impossible to have them in the first place. If mozilla separated addons into "uses stable APIs only" and "might break at any time, we may even turn them off if they cause to many crashes" that might allow users to choose which kind of model they want to follow.
- Tobu 11y ago
  XPCOM has support for stable, versioned APIs, but no one cared about using that subset since the rest was also available; it stagnated and the supposedly unstable APIs ended up bearing the compatibility burden. Now there will only be a supported subset, and the trickier stuff will require getting a patch accepted instead of monkey-patching and letting the user cope with the breakage. Your coping skills are above average, I've submitted patches too, it's still yak shaving and not a very productive use of time. Working out APIs is a hard problem, it should be handled as part of the development phase instead of being completely disconnected.

serve_yay 11y ago

> ... [cross-process object wrappers] are much slower than the equivalent DOM operations in single-process Firefox, and can affect the user experience negatively. Also, some accesses aren’t supported by the compatibility layer and will throw exceptions. Hmm, that sounds... bad?

quotemstr 11y ago
I don't see why cross-process XPCOM would have to be particularly slow. Windows is built on cross-process COM.
- TazeTSchnitzel 11y ago
  Windows isn't built on COM, Windows is built on Win32 which is a 1980s API hurriedly updated to 32-bit.

pekk 11y ago

It's only surprising if you don't understand that Mozilla's core mission now is to promote a permanent JavaScript monopoly. Mozilla has committed to blocking any technology which could ever offer equal support to any other languages. Now they cannot even allow plugins unless they are based on JavaScript. "The Web" used to mean web pages and HTTP, now "The Open Web" and "Web Technologies" mean we are forced to work with a growing mountain of ill-considered, weird and unsafe "bad parts" forever. In a strikingly similar parallel dimension, vendors have applied pressure to ensure that networked PCs would only run COBOL, and other languages could only be supported by compiling to a subset of COBOL that inherited its semantics so that nothing would ever be faster than COBOL. In that parallel dimension, this restriction is known as "Open Web", although nobody knows what is open about it.

skybrian 11y ago
It sounds like you might not like JavaScript. You should know that there are good languages that compile to JavaScript.
- pekk 11y ago
  They have the same basic semantics as JavaScript. It's not about that. Even if I liked COBOL, I wouldn't want a world where only COBOL can be used. And it doesn't make sense that this world has to be artificially enforced when there is demand for variety.
  - skybrian 11y ago
    Not sure what you mean by the "same basic semantics". I think the semantics of Go and Elm are quite far away from JavaScript. Dart less so, but it's enough to change the developer experience quite a bit. I don't particularly like x86 instructions, but they also don't bother me that often. Granted that JavaScript isn't sufficiently hidden yet, particularly in debuggers. That will take a few years. On the other hand, it's significantly more readable than assembly and getting better, so as a compiler target language, I think it will work out okay. The forces here are no more artificial than the ones that made the industry standardize on x86 and (later) ARM. Popular, accepted standards become more popular when the barriers to alternatives are very high, as can be shown by the people who tried and failed with strong alternatives.

reitanqild 11y ago

We can talk about "only approved extensions" after they have taken time to consider the pinboard extension. For now I am happy someone have told me that Pale Moon exist.

jimmaswell 11y ago

"This post really marks the final end of Firefox. The end of a truly robust Add-On model is the only thing remaining at all that sets Firefox apart. The Foundation’s constant running after being a Chrome-alike has finally run the browser into the ground fully." This comment hit the nail on the head. Really in general the browser vendors are all killing the web day by day. Maybe ~2004 to around 2013/2014 or so will be remembered as the golden age of web browsers. NPAPI worked in major browsers, you were allowed to install extensions without Mozilla or Google's permission, and Firefox had yet to mutilate its interface in an attempt to be a Chrome lookalike.

Animats 11y ago

"A major challenge we face is that many Firefox add-ons cannot possibly be built using either WebExtensions or the SDK as they currently exist." That's so Mozilla. There's a long history in add-on development of Mozilla deprecating the old thing before the new thing works. XUL/XPCOM had to go. The mobile browser, "Fennec", doesn't use it at all. But the "Jetpack" API, the one Mozilla wanted everyone to use instead of XUL/XPCOM, is apparently being deprecated as well. The announcement says it will "continue to work", but the new API seems to be completely separate from Jetpack. That probably means bugs in Jetpack won't be fixed, and bug reports will be answered with "convert to (new thing)". Mozilla AMO. Embrace the pain.

toyg 11y ago
Jetpack was such a clusterfuck. Horribly documented, released while not ready for prime time, missing basic functionality, and progressing as slowly as Italian criminal trials. I can see the point of them starting from scratch. It would have been nice if they had learnt their lesson and actually started communicating changes after they had something real to show, but alas, it seems like they're doing the same thing, just a little bit faster (maybe).
- Animats 11y ago
  "Jetpack was such a clusterfuck." Yes, and now that it pretty much works, after years of bug reports and nagging to get bugs fixed, they're deprecating it.

toyg 11y ago

It looks like a bad case of Big Rewrite. Which is mildly unsurprising, coming from an organization that was created to undertake a Big Rewrite; however, after the dismal Jetpack experience, I'm surprised they want to do it all over again, just harder and with no safety net. How can you tell your own developer community "what you're doing now, it won't be allowed next year; but what will be, we don't know yet"? You might as well tell them to go home.

thiht 11y ago

>We have decided on an approximate timeline for the deprecation of XPCOM Thank god, this undocumented crap is a nightmare to use

jaredsohn 11y ago

>Blink-compatible API in Firefox called WebExtensions Does anyone know why they are calling this API Blink-compatible rather than Chromium-compatible? My understanding is that Blink is just the rendering engine and extension code can be found within the main Chromium project. My best guess is that they are referring to it this way since I think that currently the list of browsers that use Blink is the same as the list of browsers that use Chromium code and people are more used to categorizing browsers based on their rendering engine rather than where the code originated.

dragonwriter 11y ago
> Does anyone know why they are calling this API Blink-compatible rather than Chromium-compatible? That's a good question, since the two sources they link to (from Chrome and Opera) both refer, directly or indirectly, to Chromium extensions, and neither refers to "Blink" at all.

ajnin 11y ago

We all know too well what happens when a backwards-breaking change is imposed without strong functional justifications : most developers don't actually put the effort to upgrade and as a result the vast majority of extensions break. Case in point : python modules, after tremendous effort and years of waiting about 2/3rd of the existing modules have been ported from python 2 to 3. This is relatively "mitigated" in the case of add-ons because backwards-incompatibility has become the norm so old add-ons are likely to break anyway at some point, but this still seems like a very bad idea for Mozilla to kill a large portion of their ecosystem in that single move, especially if in the bunch are very differentiating extensions like Tree Style Tabs. Justifying the decision by becoming even more interchangeable with Chrome is especially baffling, what is the strategic point of this?

TazeTSchnitzel 11y ago
Python 2/3 yielded very little benefit. That's not the case for Firefox's migration: WebExtensions are easier to write and work with other browsers.

Aardwolf 11y ago

Well, that might make me look into SeaMonkey again...

mindcrime 11y ago

Ya know, my initial reaction to this was pretty negative. As a developer, I don't like the idea of losing access to a more powerful technique in favor of a less powerful one. If I want to write an add-on, I want XPCOM / XUL, etc., at least as an option. However, giving it more thought, I think this might actually be a Good Thing in the long-run. OK, it's a stretch, but hear me out... I've been a vocal opponent of this whole idea of making the browser a poor man's operating system for a while. I want a Web where browsers are really good at, well, browsing hypermedia, and other applications handle "application stuff". So maybe, in a roundabout fashion, making it a little bit harder to extend the browser even further, will encourage people to shift back to a model of handing off some kinds of requests to an entirely different app, rather than trying to shoe-horn the kitchen sink, bathtub, 3d printer, milling machine, jumper cables, semiautomatic pistol, bandsaw, swimming pool, and clown suit all into the browser. Or maybe not. Hey, a guy can wish, right?

dragonwriter 11y ago
I think the opposite is more likely: Firefox and Chrome using the same extension mechanism -- and, inevitably, that means two-way chasing on implementing APIs that prove useful -- means that even if the ability to do more complex apps in Firefox falls in the short run, the ability to more complex apps in the browser in general (or, at least, Firefox, Chrome, and their descendants and others who adopt the same framewoek) is going to accelerate over a longer term.
- mindcrime 11y ago
  Yeah, I'm afraid you're right. :-( But like I said, a guy can wish. A more interesting question might be: "What would it take to slow down this movement towards doing everything (and then some) IN the browser"?

e12e 11y ago

Uh-oh. The main reason I use firefox is vimperator. Followed by the open source, easy to self-host sync framework, noscript and adblock. One thing I don't see anything about wrt extensions is user control. If ff is to remain relevant - signing extensions will need to come with a trust management framework. I might want to run extensions signed by Debian and myself - but not mozilla (in iceweasel). RedHat (or other vendor) might want their unbranded ff fork to only use RedHat extstensions by default; maybe with an option to also allow upstream ff signed exstensions. Without that; I see no point in signing support in a free software product?

hackuser 11y ago
Regarding Vimperator: https://billmccloskey.wordpress.com/2015/08/21/firefox-add-on-changes/ https://billmccloskey.wordpress.com/2015/08/21/firefox-add-o...
- e12e 11y ago
  Well, that's more regarding Noscript and Tree Style Tabs, actually -- it only mentions vimperator/pentadactyl in passing. Either way, thank you for the link -- hopefully the development of new APIs won't lead to a regression wrt. the add-on ecosystem :-)