TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

The Future of Developing Firefox Add-ons

281 pointsby zawaidehover 9 years ago

42 comments

scottjadover 9 years ago
A funny comment on the post:<p>&quot;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.<p>Remove that code from the core Firefox and put it where it always should have been: an extension that anyone interested can easily install.&quot;<p>And a more serious comment from a developer of DownThemAll!:<p>&quot;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…<p>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&#x2F; Add-on SDK offers, are just… toys.<p>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.&quot;<p><a href="https:&#x2F;&#x2F;blog.mozilla.org&#x2F;addons&#x2F;2015&#x2F;08&#x2F;21&#x2F;the-future-of-developing-firefox-add-ons&#x2F;comment-page-1&#x2F;#comment-218580" rel="nofollow">https:&#x2F;&#x2F;blog.mozilla.org&#x2F;addons&#x2F;2015&#x2F;08&#x2F;21&#x2F;the-future-of-dev...</a>
评论 #10098674 未加载
评论 #10098727 未加载
评论 #10099790 未加载
评论 #10099302 未加载
评论 #10098481 未加载
shockover 9 years ago
&gt; 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&#x2F;or prevent the installation of unsigned extensions.<p>This is very bad news for me. I&#x27;m a power user that prefers the balance of new features&#x2F;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&#x27;t need Mozilla to be &quot;defending&quot; me in this case.
评论 #10098539 未加载
评论 #10099824 未加载
评论 #10097936 未加载
评论 #10098016 未加载
__david__over 9 years ago
So on the one hand I love that they&#x27;re moving forward. Sometimes it&#x27;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.<p>I honestly don&#x27;t know what I&#x27;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&#x27;ll have no choice but to turn off updates and live with my current version indefinitely. And that doesn&#x27;t make me happy.
评论 #10098370 未加载
keypusherover 9 years 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&#x27;t want to have to manage multiple profiles, they don&#x27;t want to build Firefox from scratch because the version they need is not available via a package manager. I really don&#x27;t care about the rest of these changes, but they need to rethink their stance on unsigned extensions.
评论 #10098182 未加载
评论 #10098261 未加载
评论 #10100911 未加载
评论 #10098682 未加载
shinratdrover 9 years 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.<p>Judging by the number of users on Chrome, it&#x27;s hardly a dealbreaker change for most. Signing &amp; locking down extensions is a necessity. Anyone who has to deal with the user side of IT will attest to that.<p>You can&#x27;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.<p>It&#x27;s going to be an unpopular change amongst hard-core Firefox users and FF-only extension developers, but you can&#x27;t let diehards force you to drown with the ship. They&#x27;ll live and find a way. It&#x27;s regular users who will happily jump ship to Chrome, Edge and Safari without a second thought.
评论 #10099149 未加载
kibwenover 9 years ago
Standardizing the basic means of browser extension is something that I&#x27;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&#x27;t exist in Chrome, such as NoScript and Tree Style Tabs?<p>EDIT: I&#x27;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.
评论 #10097917 未加载
slasausover 9 years ago
&quot;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.&quot;<p>So to all extension developers leaning on the current permissive features or XUL&#x2F;XPCOM, please contact Mozilla and help them with finalizing their WebExtension API in the upcoming year.<p>Also, in the future if all XUL in Firefox is replaced by browser.html, there might be full customization options again based on html&#x2F;css&#x2F;js (thanks to nwah1 for pointing that out).
_wmdover 9 years ago
As a decade+ Firefox user I think this is fabulous news, not because it&#x27;ll be easier for Chrome exts to come to Firefox, but because the old extension &#x27;API&#x27; 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&#x2F;slightly incompatible API, which I&#x27;m not sure Google would have been capable of. :)<p>Chrome&#x27;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&#x2F;safe API for this specific purpose. XPCOM just exposed JS to endless unsafe internal Firefox interfaces.
评论 #10100174 未加载
shwetankover 9 years 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).<p>I think now the time is right to take a look again at NEX <a href="https:&#x2F;&#x2F;dev.opera.com&#x2F;blog&#x2F;introducing-nex&#x2F;" rel="nofollow">https:&#x2F;&#x2F;dev.opera.com&#x2F;blog&#x2F;introducing-nex&#x2F;</a> and standardising core parts of browser extensions.
simonsterover 9 years 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.<p>Here&#x27;s a list of things missing from the Chrome&#x2F;WebExtensions API that our extension currently does:<p>- Customization of the browser UI beyond a single, simple toolbar button or a few other specially implemented widgets.<p>- Reading&#x2F;writing arbitrary files to the file system. There is chrome.fileSystem, but it&#x27;s limited in what it allows, and it isn&#x27;t available to extensions, only Chrome apps.<p>- Interfacing with other applications. This typically requires using platform-native APIs, which was possible with js-ctypes (<a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Mozilla&#x2F;js-ctypes" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Mozilla&#x2F;js-ctypes</a>). Chrome has a socket API, but it&#x27;s not really the best way to do IPC, and it isn&#x27;t available to extensions anyway.<p>- Some kind of SQL database. Firefox has an SQLite interface (MozStorage), but it&#x27;s not part of the WebExtensions API. Chrome actually has WebSQL, but Firefox never implemented that (with good reason, IMO; it&#x27;s tied to a SQLite and shouldn&#x27;t be used on the web). I guess you&#x27;d better like IndexedDB.<p>- Native-looking UI widgets. This is certainly possible to do in HTML, but it&#x27;s not always so easy. For example, we have yet to find any reasonable HTML-based replacement for our tree view that&#x27;s both visually appealing on all platforms and reasonably performant with thousands of items. (If you have suggestions, let us know!)<p>I guess Mozilla&#x27;s viewpoint is that, since everyone is already supporting Chrome, they don&#x27;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&#x27;ll have is a toolkit for writing simple browser extensions.<p>I think many people use Firefox because they can customize it the way they want to. Soon you won&#x27;t be able to customize Firefox any more than Chrome. Maybe Mozilla is banking on Servo being so fast&#x2F;secure that people will use it over Chrome even when all the other advantages are gone.
评论 #10098875 未加载
评论 #10098502 未加载
评论 #10098550 未加载
评论 #10098715 未加载
superkuhover 9 years 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?<p>And getting rid of the entire firefox add-ons community is just insane. The add-ons are what makes firefox good. It&#x27;s why people use Firefox. I guess if they just want us to use Chrome this series of changes will work great.
评论 #10097797 未加载
评论 #10097805 未加载
评论 #10097907 未加载
评论 #10099200 未加载
评论 #10097751 未加载
评论 #10097739 未加载
jasonhanselover 9 years 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&#x27;m sad to see XUL extensions go; I suspect that WebExtensions will, like Google Chrome extensions, be much more limited.<p>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.<p>I&#x27;ve also always enjoyed being able to run the latest versions of extensions, which sometimes take a while to get Mozilla&#x27;s approval.<p>Are there any plans to maintain a fork of Firefox that will not include these changes?
评论 #10098235 未加载
super_marioover 9 years ago
And this is how Google killed Firefox. Why do people use Firefox? For extensions. What breaks extensions, frequent updates and extension API changes.<p>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.
评论 #10098907 未加载
评论 #10099259 未加载
nocmanover 9 years ago
&quot;we will require all extensions to be validated and signed by Mozilla starting in Firefox 41&quot;<p>I hope there is an &quot;opt out&quot; 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&#x27;t wish to share with Mozilla? I don&#x27;t particularly like having that option taken from me.<p>Yeah, I know, I could edit the source and work around it -- but based on past attempts to just <i>build</i> firefox, that could be a real pain.
评论 #10097971 未加载
mrbig4545over 9 years ago
It doesn&#x27;t mention addon permissions, which I would assume is something WebExtensions has, since that&#x27;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<p>Anyone have more info on this?
评论 #10097858 未加载
评论 #10098409 未加载
fraover 9 years ago
I worry that extensions that implement their own navigation and user experience will no longer be possible.<p>I use Vimperator extensively and would hate to see it go.<p>Chrome does have Vimium, but it is quite clunky and limited compared to the couple of Firefox solutions.
tetraodonpufferover 9 years ago
I was under the impression that add-ons like ublock &#x2F; umatrix were possible only in firefox due to its very permissive add-on model, if mozilla is going to deprecate XUL &#x2F; XPCOM would it mean this kind of add-on won&#x27;t be possible anymore?
评论 #10098118 未加载
评论 #10097896 未加载
评论 #10097847 未加载
Tobuover 9 years ago
Great news. With the current system, firefox&#x27;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&#x27;m sure the overhead helped users move to chrome, despite Firefox&#x27;s vanilla install being lighter. Reducing the API surface was a necessity.<p>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&#x27;t exist. I don&#x27;t believe that the current tradeoff of power vs responsibility was working out in the majority of cases, and I&#x27;ve seen enough evidence in the form of lagging addons and neglected ports.
评论 #10099537 未加载
annoyingdisbover 9 years 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.
fweespeechover 9 years ago
The title is a bit misleading:<p>&gt; 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.<p>This is basically the creation of a new, multi-browser API standard for browser extensions. This isn&#x27;t them just adopting a single competitor&#x27;s ecosystem. There is also a slim chance IE and Safari will join the plugin ecosystem.<p>EDIT:<p>Ty mods, this title is more reasonable.
评论 #10097963 未加载
评论 #10098113 未加载
评论 #10098951 未加载
mindcrimeover 9 years ago
Ya know, my initial reaction to this was pretty negative. As a developer, I don&#x27;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 <i>want</i> XPCOM &#x2F; XUL, etc., at least as an option.<p>However, giving it more thought, I think this might actually be a Good Thing in the long-run. OK, it&#x27;s a stretch, but hear me out... I&#x27;ve been a vocal opponent of this whole idea of making the browser a poor man&#x27;s operating system for a while. I want a Web where browsers are really good at, well, <i>browsing</i> hypermedia, and other applications handle &quot;application stuff&quot;. 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.<p>Or maybe not. Hey, a guy can wish, right?
评论 #10100946 未加载
dannysuover 9 years ago
I still don&#x27;t like that the AMO review process can take weeks and months. Mozilla even says it themselves!<p>But hopefully with WebExtension and a permission model things will get easier for getting through reviews.
Animatsover 9 years ago
<i>&quot;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.&quot;</i><p>That&#x27;s so Mozilla. There&#x27;s a long history in add-on development of Mozilla deprecating the old thing before the new thing works.<p>XUL&#x2F;XPCOM had to go. The mobile browser, &quot;Fennec&quot;, doesn&#x27;t use it at all.<p>But the &quot;Jetpack&quot; API, the one Mozilla wanted everyone to use instead of XUL&#x2F;XPCOM, is apparently being deprecated as well. The announcement says it will &quot;continue to work&quot;, but the new API seems to be completely separate from Jetpack. That probably means bugs in Jetpack won&#x27;t be fixed, and bug reports will be answered with &quot;convert to (new thing)&quot;.<p><i>Mozilla AMO. Embrace the pain.</i>
评论 #10099907 未加载
amyjessover 9 years ago
I&#x27;m really disappointed with them deprecating XUL extensions.<p>I use a number of extensions that extensively modify the UI (e.g. Tab Mix Plus), and honestly I&#x27;d rather just stick with an older version of Firefox than use Firefox without these extensions.
评论 #10099271 未加载
nevesover 9 years ago
I loved this: &quot; 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 &quot;
jaredsohnover 9 years ago
&gt;Blink-compatible API in Firefox called WebExtensions<p>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.<p>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.
评论 #10100437 未加载
toygover 9 years 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&#x27;m surprised they want to do it all over again, just harder and with no safety net.<p>How can you tell your own developer community &quot;what you&#x27;re doing now, it won&#x27;t be allowed next year; but what will be, we don&#x27;t know yet&quot;? You might as well tell them to go home.
ajninover 9 years ago
We all know too well what happens when a backwards-breaking change is imposed without strong functional justifications : most developers don&#x27;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&#x2F;3rd of the existing modules have been ported from python 2 to 3.<p>This is relatively &quot;mitigated&quot; 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.<p>Justifying the decision by becoming even more interchangeable with Chrome is especially baffling, what is the strategic point of this?
评论 #10100941 未加载
thihtover 9 years ago
&gt;We have decided on an approximate timeline for the deprecation of XPCOM<p>Thank god, this undocumented crap is a nightmare to use
scottjadover 9 years 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&#x27;t lose anything by moving to non-XUL Firefox.<p>And once they kill XUL, they can kill gecko, the maintenance of which is the bane of their job.
评论 #10099190 未加载
e12eover 9 years 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.<p>One thing I don&#x27;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.<p>Without that; I see no point in signing support in a free software product?
评论 #10101009 未加载
Illniyarover 9 years ago
Frankly the only reason I keep using Firefox instead of Chrome is because of TreestyleTabs.<p>If this change means TreestyleTabs will not work&#x2F;won&#x27;t get updated, then I don&#x27;t see myself continuing to use it.
reitanqildover 9 years ago
We can talk about &quot;only approved extensions&quot; after they have taken time to consider the pinboard extension.<p>For now I am happy someone have told me that Pale Moon exist.
serve_yayover 9 years ago
&gt; ... [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.<p>Hmm, that sounds... bad?
评论 #10099512 未加载
jimmaswellover 9 years ago
&quot;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.&quot;<p>This comment hit the nail on the head.<p>Really in general the browser vendors are all killing the web day by day. Maybe ~2004 to around 2013&#x2F;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&#x27;s permission, and Firefox had yet to mutilate its interface in an attempt to be a Chrome lookalike.
antmanover 9 years 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&#x27;t bother.
jpatel3over 9 years 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.
评论 #10102793 未加载
dafrankenstein2over 9 years ago
though its late, security review is a great thing! (maybe firefox realized its urgency after a major security flow found in Pocket.)
Nadyaover 9 years ago
&quot;To make sure that some of our users are more secure, we&#x27;re going to implement a change that will cause some of our users to refuse to update their browser - potentially making them less secure.&quot;<p>I&#x27;ve disabled updates in FF.<p>Palemoon removed Tab Groups and the addon is <i>extremely</i> buggy and doesn&#x27;t restore properly when the browser crashes. Waterfox had several issues with plugins I use.<p>I guess it&#x27;s time to fork FF and maintain my own version, implementing security patches as they come in?
评论 #10098867 未加载
Aardwolfover 9 years ago
Well, that might make me look into SeaMonkey again...
tenfingersover 9 years ago
You know, I had plenty of reasons to list about how useless signed extensions are for what they&#x27;re trying to achieve...<p>I&#x27;m even _already_ running an &quot;unbranded&quot; firefox in all my devices (iceweasel, fennec), for the same reasons I have to run chromium, so I won&#x27;t even be _directly_ affected....<p>But there&#x27;s only one thing I really want to say to Mozilla right now, as a developer:<p>Fuck you Mozilla.<p>And there&#x27;s another, as an user of which most extensions are unsigned:<p>Fuck you again, Mozilla.<p>aaah feels better.
评论 #10100899 未加载
pekkover 9 years ago
It&#x27;s only surprising if you don&#x27;t understand that Mozilla&#x27;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. &quot;The Web&quot; used to mean web pages and HTTP, now &quot;The Open Web&quot; and &quot;Web Technologies&quot; mean we are forced to work with a growing mountain of ill-considered, weird and unsafe &quot;bad parts&quot; forever.<p>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 &quot;Open Web&quot;, although nobody knows what is open about it.
评论 #10100956 未加载
评论 #10099430 未加载