8 ms·

Let’s Write a Firefox Web Extension

174 points by cpeterso 11y ago

kuschku 11y ago
Now someone just needs to write a small converter that instantly converts an existing Chrome extension for Firefox, and a script that allows people to install from the Chrome market, too, and instantly the available extensions for both browsers doubles.
- wldcordeiro 11y ago
  Most Firefox extensions are still in the older formats but it'd at least get a cross-browser extension system working.
  - kuschku 11y ago
    Well, Firefox users would still have an advantage. That Chrome users will never get addons that add tree-style tabs, or completely modify the UI, etc, is obvious. But from that point on Chrome does not have many things above Firefox anymore.
    - geofft 11y ago
      For users who primarily care about extensions, but that's been true for a while. I rarely use extensions (currently I'm using, uh, Google Cast, plus the mosh Chrome app because life's too short to install software) and I care about security, and Chrome's multiprocess and sandboxed architecture has significant wins there. When Firefox gets that, then I'd agree that at least for me, Chrome won't have many things above Firefox any more. And the new extension system is part of their plan for getting there.
      - chimeracoder 11y ago
        > Chrome's multiprocess and sandboxed architecture has significant wins there. When Firefox gets that, Multiprocess is currently enabled by default on desktop in the Firefox developer edition. And the release version of Firefox on Android is multiprocess and also supports extensions.
        Tobu 11y ago
        In practice, about half the extensions I use (the complex ones, like Lazarus) need a serious overhaul to work with e10s. It can't hit a stable release, there would be major breakage.
        viraptor 11y ago
        There's a difference between chrome and ff multiprocess. The sandbox model (at least on linux) in chrome is better than anything else available right now. They're pretty much the reason that kernel-level sandbox is available to us now.
        geofft 11y ago
        Hm, both viraptor and I were downvoted without significant commentary. While I don't mind downvotes for being wrong, is anyone interested in actually claiming that we're wrong? As far as I'm aware, viraptor is completely technically accurate: the Chrome team is the reason that Linux's seccomp mode 2 is so good today. (In 2010-11 I was working on a project that assumed that the seccomp mode 2 rumors were never going to amount to anything, which was the consensus of the time.) Also while I'm here, a certain [dead]-and-proud account linked this bug which is somewhat relevant (but only somewhat, in my eyes): https://code.google.com/p/chromium/issues/detail?id=477424 https://code.google.com/p/chromium/issues/detail?id=477424
        kuschku 11y ago
        I don’t know enough about the sandbox model to discuss it (and I know that Google tries to have an amazing sandbox model especially because they run their browser also as OS) But the sidebar stuff just can’t compete with the whole browser UI being effectively an XML document in the hands of an extension.
        viraptor 11y ago
        There were lots of interesting extensions doing crazy stuff with the UI at the beginning. Then they got split into some specific types, like: icon/action, content processing, extra information (typically as a side/top/bottom bar). To the point that I can't even think of one that doesn't fit in those scenarios. The extension authors were invited to comment on what's needed from the extension API to support their use case. So are you one of the extension authors, or users? What exactly do you want to change in the UI and did you raise an issue with google or mozilla?
    - ossreality 11y ago
      Yeah, except reality: https://code.google.com/p/chromium/issues/detail?id=477424 https://code.google.com/p/chromium/issues/detail?id=477424
- nathancahill 11y ago
  It's been tried[0][1][2], but doesn't work very well. Similar to how PhoneGap tries to create a cross platform solution, it will always feel kludgy compared to developing with native APIs. [0] http://kangoextensions.com/ http://kangoextensions.com/ [1] http://crossrider.com/developers http://crossrider.com/developers [2] http://crossbrowser.com/ http://crossbrowser.com/
  - kuschku 11y ago
    Well, with this new API Chrome extensions run natively in Firefox, if one adds a single tag to the metadata json file. So, doing this should be easy.
    - nathancahill 11y ago
      I wouldn't phrase it like that. Instead, Firefox is implementing a similar extension API, which overlaps with Chrome and Opera's APIs. What you described, "instantly converting an existing Chrome extension for Firefox" is a long ways off. There's a lot of gaps in Mozilla's implementation right now. To do anything interesting (beyond cat gifs), you have to fall back to the old QueryInterface/ns* APIs.
      - voltagex_ 11y ago
        Are we still allowed to use the old APIs? See http://www.downthemall.net/the-likely-end-of-downthemall/ http://www.downthemall.net/the-likely-end-of-downthemall/
        nathancahill 11y ago
        From the original post[0]: > 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. [0] https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/ https://blog.mozilla.org/addons/2015/08/21/the-future-of-dev...
Tobu 11y ago
At the moment there are more gaps than API and the debugging experience is such that you have to go back and forth between Chrome (debugging any changes you made) and Firefox (looking at the global console, checking that you're within the small supported subset). Recommending gulp is ridiculous overkill. Chrome loads files from disk directly, Firefox plans to.
mtgx 11y ago
> The only thing I would add is that while Mozilla is implementing most of the API that Chrome and Opera support, we’re not restricting ourselves to only that API. Where it makes sense, we will be adding new functionality and talking with other browser makers about implementing it as well. At least focus on making it possible to do secure communications inside a browser, where for instance you may not want to trust the service provider and want to do the crypto locally. I know for instance that Nadim Kobeissi was in the past praising Chrome for its packaged apps and how they allow better security for Cryptocat than Firefox does. Make extensions such as Mailvelope be at least as secure as native apps. Focus on stuff like that rather than enabling extensions to change how the browser looks, which likely introduce their own security vulnerabilities by design (I know many have cried about stuff like that when you announced deprecating the old add-on model). Maybe even do that with browser components that are written in Rust. Speaking as a Chrome user and very occasional Firefox user, the more Rust you use the higher the chance you'll have to convert someone like me who cares about security and continues to choose Chrome based on that. The sooner your sandboxing architecture is on par with Chrome's the better as well. Someone like me is not "just a niche". It's also the type of person that recommends (evangelizes even) a browser or app to every single friend he has. Don't forget that's exactly how Chrome "beat" Firefox, if I can say that - by winning over the evangelists.
- ronjouch 11y ago
  > Someone like me is not "just a niche". It's also the type of person that recommends (evangelizes even) a browser or app to every single friend he has. Don't forget that's exactly how Chrome "beat" Firefox, if I can say that - by winning over the evangelists. You're saying "don't forget that..." as if that was an established fact, but did studies confirm this? I doubt it. I don't have numbers either so that's only one feeling against another, but I think you overstate the importance of evangelists / "power users" like us. There are other factors that (to my eyes) seem much more likely to have pushed users towards Chrome, like: - Giant physical ads in subways (in London, Paris, Amsterdam, Berlin, maybe others?). - More ads on the web. - Very visible hints to switch on high-volume domains like google.com and youtube.com - Chrome having a mobile story earlier letting users sync their bookmarks & passwords across devices. By comparison, Firefox (with Firefox Sync) took some time to land on Android, and is barely arriving on iOS. - The sorry memory-hungry, inefficient state of Firefox when Chrome was young and slim (which was fixed since then, but hurt the Firefox brand a lot).
haddr 11y ago
Really looking forward to some sort of interoperability between browsers plugins between Chrome and Firefox. That would be really great. However my intuition tells me thats going to be quite difficult. Not only from the technical point of view but also the perspective of developers of existing extensions... Would there be some common extension repository? What if someone takes somebody else's Chrome extension and puts it in the FF repo as his own, etc...
lemevi 11y ago
Any break from the XUL days are a huge plus. XUL gives you so much power but is very unsafe for the users since anything goes and that system is also very poorly documented. I sometimes had to look at the Mozilla source code to understand what was possible with the XUL based extension system. Now that we have a really great set of native dev tools inside Firefox maybe we don't need XUL anymore? I say that because maybe something like Firebug isn't possible without XUL.
mindcrime 11y ago
It would be pretty awesome if we can get to a place where browser extensions are truly cross-browser. At least for some definition of "browser extension". I'd be OK with a "common core" that's cross-browser, and the browser makers continuing to support their own extension APIs as well, IF the "core" API never becomes as powerful as the old, native APIs. I'd hate to see the native APIs go away completely though, as I don't like the idea of artificially restricting the range of possible plugins. Then again, I am already annoyed by Chrome ditching NPAPI and leaving us in a place where, AFAIK, you can't run the Java plugin in Chrome. OTOH, JWS still works (I think) which is something at least...
- FreakyT 11y ago
  To be fair, no one should be using Java applets in this day and age, and hopefully this will finally kill them off for good.
  - drdeca 11y ago
    Though, now you can't make certain types of sockets in browser...
    - mmebane 11y ago
      Nor can you integrate with the local filesystem, or call native APIs. With a hidden Java applet, it was pretty easy to make a full-fledged application that just happened to have a web-based API. That's getting a lot harder. Chrome extensions have an API called Native Messaging which is roughly the postMessage API over stdin/stdout. It works, but isn't cross-browser. Alternatively, you can start up a local server and make XHR or WebSocket calls to localhost. However, both of those require the user going through an external install process. Maybe, in the current security landscape, that's the way it has to be, but it's kind of annoying.
  - mindcrime 11y ago
    Not sure I agree with that. I like, for example, the Java applet that goes with FreeMind for viewing mindmaps.
Mindless2112 11y ago
So killing off XUL is great and all, but two of my favorite add-ons [1] [2] are already planning to call it quits because the Web Extension API likely won't be powerful enough. Tree Style Tab isn't far behind, I'll bet. These add-ons are the reason I use Firefox. It seems like Firefox is going to become just another browser. [1] http://www.downthemall.net/the-likely-end-of-downthemall/ http://www.downthemall.net/the-likely-end-of-downthemall/ [2] https://github.com/sparhami/BeQuiet/issues/2 https://github.com/sparhami/BeQuiet/issues/2
- javajosh 11y ago
  Oh come now, that's not fair. Sure XUL can't be the key to a good extension mechanism. If devs stop writing (or choose not to port) it's because of the economics of Firefox extensions, which is to say, there are no economics to writing Firefox extensions. Except some minor reputation points and feel-good points. (The exception, of course, being those add-ons that make a SaaS more usable.) Out of curiosity, if there was a Firefox App Store, how much would you pay for Tree Style Tabs?
  - yellowapple 11y ago
    > Out of curiosity, if there was a Firefox App Store, how much would you pay for Tree Style Tabs? Probably a few bucks. TST is pretty fundamental to my Firefox workflow.
    - deleted 11y ago
      [deleted]
    - Qantourisc 11y ago
      Well according to Mozilla TST has 100 000 users. At a few bucks that's 300 000$ I suppose that could be enough :) With that money you can even maintain a separate Firefox patch-set to allow the plugin to work.
  - mafuyu 11y ago
    I would pay a significant amount of money for pentadactyl + Tree Style Tabs that just worked, without bugs. It's a significant part of my workflow, and I'm not sure if either will survive XUL deprecation. :(
_ZeD_ 11y ago
from the article: >>> [...] I think it’s time to add a build script. I hear that the go-to build tool these days is gulp, so I’ll wait here while you go install that, and c’mon back when you’re done. (I needed to install Node, and then gulp twice. I’m not sure why.) what should have been: I hear that the go-to build tool these days is gulp, but fuck gulp and use make.
darklajid 11y ago
Wait. Isn't that the browser¹ that requires you to use an online certification process to install even your own addons/developments, unless you're on a Nightly version and change a hidden setting? skims the article Ah yeah, they avoid the subject by using Nightly anyway due to the changing API. Note that any build other than Nightly won't let you install unsigned extensions, period. Not by changing about:config values or in any way for form I'd know about. ①: Firefox fan forever. Since they decided that no, you are not allowed to install your own build of Vimperator/TST etc. without a signature from Mozilla, I'm looking for alternatives. Unfortunately there's no real competition, it's either Chrome or FF - and FF seems to move into directions I don't like.
- kevingadd 11y ago
  You can install unsigned addons in Developer Edition. I've been using Developer Edition as my primary browser for over a year. If you're the kind of power user that needs to install unsigned extensions, it's a pretty reasonable compromise... You can always build release channel from source. Adding a pref to release/beta for this would defeat some of the purpose of the feature - bad actors always find ways to install their shitty extensions into the browser. When the browser does signing checks before loading them, that raises the challenge significantly vs. setting some prefs and dropping a file in the right place. Chrome has a similar extension policy. Edge probably will too. History has shown that nothing less than this will cut it. :-(
  - darklajid 11y ago
    I feel that Developer Edition would solve my problem. That said: Building FF from source takes ages. It's not something I like to do, honestly, to build/package/install a couple of JS files. And I do think that this is a crappy idea. Okay, require signatures if you want to install something directly from the web, maybe? But if I point that thing at a .xpi file, locally, let me install that. Hide it behind a flag in about:config, but let me install that. Saying 'ah, but someone might toggle that box for you' is weird and reminds me of Raymond Chen's 'Wrong side of the hatch' security reports. If you can do that, if your installer can mess with my about:config, why can't it f* up my whole system? A free idea for malware distributors: Bundle your own release channel build of FF and just remove the official one, keep the user's profile. Your MSI runs elevated, I'm reasonably sure I could do that ~somewhat easily~, if you make your money with shady stuff you're bound to make this work. Tada! Every extension can be installed again, please add a couple useful and set a decent home page. The premise is crap. The implementation is unfortunate and follows the premise. (Again: Thanks for the DE hint. That's listed in [1] as well, I must have missed that in the past and - Nightly isn't exactly what I want to run on a daily basis. Or at least not as my main browser, a side by side install is often present on my machines) [1]: https://wiki.mozilla.org/Addons/Extension_Signing https://wiki.mozilla.org/Addons/Extension_Signing
stewbrew 11y ago
... and in FF50 they'll replace gecko with blink to be on par with chrome and opera. Seriously, I use firefox because of its addons, for which no equivalent exists for chrome, e.g. downthemall, shelve, tiddlyfox. As it looks there is little chance, these addons will continue to work with future releases of ff. So why should I continue using FF?

174 points by cpeterso 11y ago

Now someone just needs to write a small converter that instantly converts an existing Chrome extension for Firefox, and a script that allows people to install from the Chrome market, too, and instantly the available extensions for both browsers doubles.

wldcordeiro 11y ago
Most Firefox extensions are still in the older formats but it'd at least get a cross-browser extension system working.
- kuschku 11y ago
  Well, Firefox users would still have an advantage. That Chrome users will never get addons that add tree-style tabs, or completely modify the UI, etc, is obvious. But from that point on Chrome does not have many things above Firefox anymore.
  - geofft 11y ago
    For users who primarily care about extensions, but that's been true for a while. I rarely use extensions (currently I'm using, uh, Google Cast, plus the mosh Chrome app because life's too short to install software) and I care about security, and Chrome's multiprocess and sandboxed architecture has significant wins there. When Firefox gets that, then I'd agree that at least for me, Chrome won't have many things above Firefox any more. And the new extension system is part of their plan for getting there.
    - chimeracoder 11y ago
      > Chrome's multiprocess and sandboxed architecture has significant wins there. When Firefox gets that, Multiprocess is currently enabled by default on desktop in the Firefox developer edition. And the release version of Firefox on Android is multiprocess and also supports extensions.
      - Tobu 11y ago
        In practice, about half the extensions I use (the complex ones, like Lazarus) need a serious overhaul to work with e10s. It can't hit a stable release, there would be major breakage.
      - viraptor 11y ago
        There's a difference between chrome and ff multiprocess. The sandbox model (at least on linux) in chrome is better than anything else available right now. They're pretty much the reason that kernel-level sandbox is available to us now.
        geofft 11y ago
        Hm, both viraptor and I were downvoted without significant commentary. While I don't mind downvotes for being wrong, is anyone interested in actually claiming that we're wrong? As far as I'm aware, viraptor is completely technically accurate: the Chrome team is the reason that Linux's seccomp mode 2 is so good today. (In 2010-11 I was working on a project that assumed that the seccomp mode 2 rumors were never going to amount to anything, which was the consensus of the time.) Also while I'm here, a certain [dead]-and-proud account linked this bug which is somewhat relevant (but only somewhat, in my eyes): https://code.google.com/p/chromium/issues/detail?id=477424 https://code.google.com/p/chromium/issues/detail?id=477424
        kuschku 11y ago
        I don’t know enough about the sandbox model to discuss it (and I know that Google tries to have an amazing sandbox model especially because they run their browser also as OS) But the sidebar stuff just can’t compete with the whole browser UI being effectively an XML document in the hands of an extension.
        viraptor 11y ago
        There were lots of interesting extensions doing crazy stuff with the UI at the beginning. Then they got split into some specific types, like: icon/action, content processing, extra information (typically as a side/top/bottom bar). To the point that I can't even think of one that doesn't fit in those scenarios. The extension authors were invited to comment on what's needed from the extension API to support their use case. So are you one of the extension authors, or users? What exactly do you want to change in the UI and did you raise an issue with google or mozilla?
  - ossreality 11y ago
    Yeah, except reality: https://code.google.com/p/chromium/issues/detail?id=477424 https://code.google.com/p/chromium/issues/detail?id=477424
nathancahill 11y ago
It's been tried[0][1][2], but doesn't work very well. Similar to how PhoneGap tries to create a cross platform solution, it will always feel kludgy compared to developing with native APIs. [0] http://kangoextensions.com/ http://kangoextensions.com/ [1] http://crossrider.com/developers http://crossrider.com/developers [2] http://crossbrowser.com/ http://crossbrowser.com/
- kuschku 11y ago
  Well, with this new API Chrome extensions run natively in Firefox, if one adds a single tag to the metadata json file. So, doing this should be easy.
  - nathancahill 11y ago
    I wouldn't phrase it like that. Instead, Firefox is implementing a similar extension API, which overlaps with Chrome and Opera's APIs. What you described, "instantly converting an existing Chrome extension for Firefox" is a long ways off. There's a lot of gaps in Mozilla's implementation right now. To do anything interesting (beyond cat gifs), you have to fall back to the old QueryInterface/ns* APIs.
    - voltagex_ 11y ago
      Are we still allowed to use the old APIs? See http://www.downthemall.net/the-likely-end-of-downthemall/ http://www.downthemall.net/the-likely-end-of-downthemall/
      - nathancahill 11y ago
        From the original post[0]: > 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. [0] https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/ https://blog.mozilla.org/addons/2015/08/21/the-future-of-dev...

Tobu 11y ago

At the moment there are more gaps than API and the debugging experience is such that you have to go back and forth between Chrome (debugging any changes you made) and Firefox (looking at the global console, checking that you're within the small supported subset). Recommending gulp is ridiculous overkill. Chrome loads files from disk directly, Firefox plans to.

mtgx 11y ago

> The only thing I would add is that while Mozilla is implementing most of the API that Chrome and Opera support, we’re not restricting ourselves to only that API. Where it makes sense, we will be adding new functionality and talking with other browser makers about implementing it as well. At least focus on making it possible to do secure communications inside a browser, where for instance you may not want to trust the service provider and want to do the crypto locally. I know for instance that Nadim Kobeissi was in the past praising Chrome for its packaged apps and how they allow better security for Cryptocat than Firefox does. Make extensions such as Mailvelope be at least as secure as native apps. Focus on stuff like that rather than enabling extensions to change how the browser looks, which likely introduce their own security vulnerabilities by design (I know many have cried about stuff like that when you announced deprecating the old add-on model). Maybe even do that with browser components that are written in Rust. Speaking as a Chrome user and very occasional Firefox user, the more Rust you use the higher the chance you'll have to convert someone like me who cares about security and continues to choose Chrome based on that. The sooner your sandboxing architecture is on par with Chrome's the better as well. Someone like me is not "just a niche". It's also the type of person that recommends (evangelizes even) a browser or app to every single friend he has. Don't forget that's exactly how Chrome "beat" Firefox, if I can say that - by winning over the evangelists.

ronjouch 11y ago
> Someone like me is not "just a niche". It's also the type of person that recommends (evangelizes even) a browser or app to every single friend he has. Don't forget that's exactly how Chrome "beat" Firefox, if I can say that - by winning over the evangelists. You're saying "don't forget that..." as if that was an established fact, but did studies confirm this? I doubt it. I don't have numbers either so that's only one feeling against another, but I think you overstate the importance of evangelists / "power users" like us. There are other factors that (to my eyes) seem much more likely to have pushed users towards Chrome, like: - Giant physical ads in subways (in London, Paris, Amsterdam, Berlin, maybe others?). - More ads on the web. - Very visible hints to switch on high-volume domains like google.com and youtube.com - Chrome having a mobile story earlier letting users sync their bookmarks & passwords across devices. By comparison, Firefox (with Firefox Sync) took some time to land on Android, and is barely arriving on iOS. - The sorry memory-hungry, inefficient state of Firefox when Chrome was young and slim (which was fixed since then, but hurt the Firefox brand a lot).

haddr 11y ago

Really looking forward to some sort of interoperability between browsers plugins between Chrome and Firefox. That would be really great. However my intuition tells me thats going to be quite difficult. Not only from the technical point of view but also the perspective of developers of existing extensions... Would there be some common extension repository? What if someone takes somebody else's Chrome extension and puts it in the FF repo as his own, etc...

lemevi 11y ago

Any break from the XUL days are a huge plus. XUL gives you so much power but is very unsafe for the users since anything goes and that system is also very poorly documented. I sometimes had to look at the Mozilla source code to understand what was possible with the XUL based extension system. Now that we have a really great set of native dev tools inside Firefox maybe we don't need XUL anymore? I say that because maybe something like Firebug isn't possible without XUL.

mindcrime 11y ago

It would be pretty awesome if we can get to a place where browser extensions are truly cross-browser. At least for some definition of "browser extension". I'd be OK with a "common core" that's cross-browser, and the browser makers continuing to support their own extension APIs as well, IF the "core" API never becomes as powerful as the old, native APIs. I'd hate to see the native APIs go away completely though, as I don't like the idea of artificially restricting the range of possible plugins. Then again, I am already annoyed by Chrome ditching NPAPI and leaving us in a place where, AFAIK, you can't run the Java plugin in Chrome. OTOH, JWS still works (I think) which is something at least...

FreakyT 11y ago
To be fair, no one should be using Java applets in this day and age, and hopefully this will finally kill them off for good.
- drdeca 11y ago
  Though, now you can't make certain types of sockets in browser...
  - mmebane 11y ago
    Nor can you integrate with the local filesystem, or call native APIs. With a hidden Java applet, it was pretty easy to make a full-fledged application that just happened to have a web-based API. That's getting a lot harder. Chrome extensions have an API called Native Messaging which is roughly the postMessage API over stdin/stdout. It works, but isn't cross-browser. Alternatively, you can start up a local server and make XHR or WebSocket calls to localhost. However, both of those require the user going through an external install process. Maybe, in the current security landscape, that's the way it has to be, but it's kind of annoying.
- mindcrime 11y ago
  Not sure I agree with that. I like, for example, the Java applet that goes with FreeMind for viewing mindmaps.

Mindless2112 11y ago

So killing off XUL is great and all, but two of my favorite add-ons [1] [2] are already planning to call it quits because the Web Extension API likely won't be powerful enough. Tree Style Tab isn't far behind, I'll bet. These add-ons are the reason I use Firefox. It seems like Firefox is going to become just another browser. [1] http://www.downthemall.net/the-likely-end-of-downthemall/ http://www.downthemall.net/the-likely-end-of-downthemall/ [2] https://github.com/sparhami/BeQuiet/issues/2 https://github.com/sparhami/BeQuiet/issues/2

javajosh 11y ago
Oh come now, that's not fair. Sure XUL can't be the key to a good extension mechanism. If devs stop writing (or choose not to port) it's because of the economics of Firefox extensions, which is to say, there are no economics to writing Firefox extensions. Except some minor reputation points and feel-good points. (The exception, of course, being those add-ons that make a SaaS more usable.) Out of curiosity, if there was a Firefox App Store, how much would you pay for Tree Style Tabs?
- yellowapple 11y ago
  > Out of curiosity, if there was a Firefox App Store, how much would you pay for Tree Style Tabs? Probably a few bucks. TST is pretty fundamental to my Firefox workflow.
  - deleted 11y ago
    [deleted]
  - Qantourisc 11y ago
    Well according to Mozilla TST has 100 000 users. At a few bucks that's 300 000$ I suppose that could be enough :) With that money you can even maintain a separate Firefox patch-set to allow the plugin to work.
- mafuyu 11y ago
  I would pay a significant amount of money for pentadactyl + Tree Style Tabs that just worked, without bugs. It's a significant part of my workflow, and I'm not sure if either will survive XUL deprecation. :(

_ZeD_ 11y ago

from the article: >>> [...] I think it’s time to add a build script. I hear that the go-to build tool these days is gulp, so I’ll wait here while you go install that, and c’mon back when you’re done. (I needed to install Node, and then gulp twice. I’m not sure why.) what should have been: I hear that the go-to build tool these days is gulp, but fuck gulp and use make.

darklajid 11y ago

Wait. Isn't that the browser¹ that requires you to use an online certification process to install even your own addons/developments, unless you're on a Nightly version and change a hidden setting? skims the article Ah yeah, they avoid the subject by using Nightly anyway due to the changing API. Note that any build other than Nightly won't let you install unsigned extensions, period. Not by changing about:config values or in any way for form I'd know about. ①: Firefox fan forever. Since they decided that no, you are not allowed to install your own build of Vimperator/TST etc. without a signature from Mozilla, I'm looking for alternatives. Unfortunately there's no real competition, it's either Chrome or FF - and FF seems to move into directions I don't like.

kevingadd 11y ago
You can install unsigned addons in Developer Edition. I've been using Developer Edition as my primary browser for over a year. If you're the kind of power user that needs to install unsigned extensions, it's a pretty reasonable compromise... You can always build release channel from source. Adding a pref to release/beta for this would defeat some of the purpose of the feature - bad actors always find ways to install their shitty extensions into the browser. When the browser does signing checks before loading them, that raises the challenge significantly vs. setting some prefs and dropping a file in the right place. Chrome has a similar extension policy. Edge probably will too. History has shown that nothing less than this will cut it. :-(
- darklajid 11y ago
  I feel that Developer Edition would solve my problem. That said: Building FF from source takes ages. It's not something I like to do, honestly, to build/package/install a couple of JS files. And I do think that this is a crappy idea. Okay, require signatures if you want to install something directly from the web, maybe? But if I point that thing at a .xpi file, locally, let me install that. Hide it behind a flag in about:config, but let me install that. Saying 'ah, but someone might toggle that box for you' is weird and reminds me of Raymond Chen's 'Wrong side of the hatch' security reports. If you can do that, if your installer can mess with my about:config, why can't it f* up my whole system? A free idea for malware distributors: Bundle your own release channel build of FF and just remove the official one, keep the user's profile. Your MSI runs elevated, I'm reasonably sure I could do that ~somewhat easily~, if you make your money with shady stuff you're bound to make this work. Tada! Every extension can be installed again, please add a couple useful and set a decent home page. The premise is crap. The implementation is unfortunate and follows the premise. (Again: Thanks for the DE hint. That's listed in [1] as well, I must have missed that in the past and - Nightly isn't exactly what I want to run on a daily basis. Or at least not as my main browser, a side by side install is often present on my machines) [1]: https://wiki.mozilla.org/Addons/Extension_Signing https://wiki.mozilla.org/Addons/Extension_Signing

stewbrew 11y ago

... and in FF50 they'll replace gecko with blink to be on par with chrome and opera. Seriously, I use firefox because of its addons, for which no equivalent exists for chrome, e.g. downthemall, shelve, tiddlyfox. As it looks there is little chance, these addons will continue to work with future releases of ff. So why should I continue using FF?