Add-ons in 2017 • Hacker News Board

Re: Add-ons in 2017

#101

Post by noisem4ker » Thu, Nov 24, 2016, 9:11 PM UTC

duskwuff wrote: post #95

alphapapa wrote: post #75

Earlier quoted context omitted.

I'm sorry, but I hear this all the time--it's the primary argument used for deprecating or removing any functionality in any software. And my response is: so what? Maintaining software is a burden, period. Software exists to be useful. The APIs in question make it useful. The developers have been maintaining it for nearly 20 years. Their employer receives millions of dollars a year to do so. They don't want to mainta…

With regard to resumable downloads -- that "cleverness" isn't for the sake of being clever; it's in there to avoid two very common cases where a naïve download resume will corrupt a file: 1. The remote file has changed since the previous download, so "resuming" the download will end up combining two different files. 2. The user's computer crashed during the first download, and some of the data in the partial download…

1. Date / file size check. In doubt, ask the user.

2. Rollback a few megabytes.

These problems were solved ages ago by most download managers.

Re: Add-ons in 2017

#102

Post by hackuser » Thu, Nov 24, 2016, 9:29 PM UTC

tn123 wrote: post #79

Yoric wrote: post #33

Earlier quoted context omitted.

The WebExtensions team has been very proactive, attempting to get in touch with add-on developers across the spectrum. If the add-on developers have responded, there's a 99% chance that new APIs will be available for their add-ons.

Sorry, but that is just wrong, Certain types of APIs are infeasible to provide, because mozilla is too time and resource constrained to invest major resources into spec'ing, implementing and maintaining "niche" APIs. So far, Firefox did not even manage to reach chrome parity, let alone bug parity. If you look at the Advisory Group meeting notes (in charge of new APIs AFAIK), there is almost nothing still: https://doc…

From Giorgio Maone, developer of one of the most complex and most popular extensions, NoScript:

Developers and users are also concerned about add-ons being prevented from exploring radically new concepts which would require those "super powers" apparently taken away by the WebExtensions API.

I'd like to reassure them: Mozilla is investing a lot of resources to ensure that complex and innovative extensions can prosper also in the new Web-centric ecosystem. In fact, as mentioned by Bill McCloskey, at this moment I'm working within Mozilla's Electrolysis team and with other add-on authors, involved in the design of mechanisms and processes helping developers experiment in directions not supported yet by the "official" the WebExtensions API, which is going to be augmented and shaped around their needs and with their contributions.

https://hackademix.net/2015/08/22/webextensions-api-noscript...

Re: Add-ons in 2017

#103

Post by Macha » Thu, Nov 24, 2016, 10:13 PM UTC

Yoric wrote: post #21

hucker wrote: post #10

Extensions is currently the only thing FF is better than the competition at, and they scrap it to copy Chrome APIs... I just can't understand why they would scrap XUL-based extensions before their new APIs reach feature parity. The day pentadactyl stops working is the day I stop using firefox.

Well, XUL-based extensions are not scraped yet. They will, at some point in 2017, but we're not there yet. The reason to scrape them is simple: the total API surface of XUL-based extensions is pretty much all of the internal APIs of Firefox, which means that any change anywhere in the code of Firefox breaks some extension accidentally. That's a compatibility burden that Mozilla could afford when the only competitor w…

> which means that any change anywhere in the code of Firefox breaks some extension accidentally

So to fix this they're going to break every extension.

I think it's a fair assumption given how long the current extension API has been around that there will be more extensions that will die to disinterest or inability to move to WebExtensions than have been broken by all firefox releases from 4.0 to date.

Re: Add-ons in 2017

#104

Post by majewsky » Thu, Nov 24, 2016, 11:06 PM UTC

myfonj wrote: post #26

morinted wrote: post #2

I'd love some figures on whether the main popular extensions will continue working, as well as how many in the Firefox Add-ons site are already web extensions. I'm curious about my mains: - Classic theme restorer - uBlock - DownThemAll - Markdown Here As I'm already using electrolysis, I know Markdown Here basically doesn't work. How I can check whether things will break or not.

You can consult https://www.arewee10syet.com/ ; seems authors are mostly showing some efforts to migrate their extensions. CTR: seems OK, uBlock: uBockO: seems OK, DTA: bug, but at least tries to be e10s compatible, Mardown here: unknown (supposedly not compatible?) You can try yourself: either install https://nightly.mozilla.org/ and load it with your addons (it uses different profile) or use your stable one and loo…

Careful. The e10s transition is a much smaller step than the move to WebExtensions. To witness, notice how (higher up in this thread) the DTA developer once again said that there will be no DTA as a WebExtension.

Re: Add-ons in 2017

#105

Post by johnny22 » Thu, Nov 24, 2016, 11:19 PM UTC

alphapapa wrote: post #66

Yoric wrote: post #31

Earlier quoted context omitted.

As a Firefox developer, whenever I make a change (and I mean pretty much any change to an API accessible through platform JS), I have two choices: 1/ either try and locate all the add-ons that will be broken, get in touch with their developers, be ignored by most of them, start several weeks of negotiation with those who do answer, then eventually, several months after my code is ready, land the change, and notice th…

> 1/ either try and locate all the add-ons that will be broken, get in touch with their developers, be ignored by most of them, start several weeks of negotiation with those who do answer, then eventually, several months after my code is ready, land the change, and notice that Chrome has landed that same change a few months ago (emphasis mine) And responding to that emphasis: so what?! People who use Firefox instead…

Mozilla's roadmap for the future is what's keeping me on the Firefox train, and not making me jump off it in favor of Chrome.

In any case, you certainly don't speak for all Firefox users.

Re: Add-ons in 2017

#106

Post by Sylos » Thu, Nov 24, 2016, 11:37 PM UTC

tn123 wrote: post #79

Yoric wrote: post #33

Earlier quoted context omitted.

The WebExtensions team has been very proactive, attempting to get in touch with add-on developers across the spectrum. If the add-on developers have responded, there's a 99% chance that new APIs will be available for their add-ons.

Sorry, but that is just wrong, Certain types of APIs are infeasible to provide, because mozilla is too time and resource constrained to invest major resources into spec'ing, implementing and maintaining "niche" APIs. So far, Firefox did not even manage to reach chrome parity, let alone bug parity. If you look at the Advisory Group meeting notes (in charge of new APIs AFAIK), there is almost nothing still: https://doc…

> Sorry, but that is just wrong, Certain types of APIs are infeasible to provide, because mozilla is too time and resource constrained to invest major resources into spec'ing, implementing and maintaining "niche" APIs.

I don't know how you come to this conclusion. They've been able to maintain XUL up until now and whatever they end up with in this new API, it'll be cheaper to maintain than the monstrosity that is XUL extensions.

The specification and implementation are done in cooperation with the add-on developers. They can draw from the community here.

And while they haven't reached Chrome parity yet, they do have already implemented some additional APIs. You're writing as if one thing would block the other.

Re: Add-ons in 2017

#107

Post by Sylos » Thu, Nov 24, 2016, 11:47 PM UTC

nv-vn wrote: post #40

And this is how Mozilla goes out. Their last remaining reason for existence is being destroyed. They've already gotten rid of Thunderbird, Tab Groups, full themes, and more, but left us with the things nobody wanted (Pocket, Hello, etc.). They've also slowly let performance go in many places, seemingly. A few years ago, I switched to Firefox for precisely the set of features they've axed. It was also much faster than…

If you have significant lock-ups once an hour, you should troubleshoot. Probably one of your add-ons causing the issue. Your RAM usage might very well go down with that as well, and if you disable a few of your add-ons during troubleshooting, chances are also that Electrolysis (multiprocess) will get enabled for you, which should significantly improve performance.

Re: Add-ons in 2017

#108

Post by Sylos » Fri, Nov 25, 2016, 12:07 AM UTC

yoodenvranx wrote: post #53

myfonj wrote: post #26

Earlier quoted context omitted.

You can consult https://www.arewee10syet.com/ ; seems authors are mostly showing some efforts to migrate their extensions. CTR: seems OK, uBlock: uBockO: seems OK, DTA: bug, but at least tries to be e10s compatible, Mardown here: unknown (supposedly not compatible?) You can try yourself: either install https://nightly.mozilla.org/ and load it with your addons (it uses different profile) or use your stable one and loo…

Total Mozilla noob here: Tab Mix Plus shows up as compatible. Does that mean that I will be able to use it with the new extension system?

No, what this check means is that the recently introduced multiprocess-features of Firefox won't be blocked by Tab Mix Plus. You'll get much better performance, if you have no extensions which block that.

The guy seems to be confusing things here, too.

But while this doesn't confirm it, it neither confirms the opposite. So, it is very much still possible thst Tab Mix Plus gets ported to WebExtensions before the old add-ons get shut off, i.e. you might very well be able to use it still then, there's just currently no way to know yet.

And as far as I can tell, the developer seems to have accepted porting it to WebExtensions and will most likely do it: http://tabmixplus.org/forum/viewtopic.php?f=1&t=19282

Re: Add-ons in 2017

#109

Post by morinted » Fri, Nov 25, 2016, 12:38 AM UTC

gorhill wrote: post #67

morinted wrote: post #2

I'd love some figures on whether the main popular extensions will continue working, as well as how many in the Firefox Add-ons site are already web extensions. I'm curious about my mains: - Classic theme restorer - uBlock - DownThemAll - Markdown Here As I'm already using electrolysis, I know Markdown Here basically doesn't work. How I can check whether things will break or not.

uBlock Origin was first developed as a Chromium extension, so converting to WebExtensions API is a non-issue. There is currently a dev build for the WebExtension version of uBlock Origin in the latest release.[1] FYI, uBlock is abandonware[2]. [1] https://github.com/gorhill/uBlock/releases (search for "webext") [2] https://github.com/chrisaljoudi/uBlock/releases ("released this on 31 May 2015")

Thanks for your comment. I should have specified uBlock Origin; I meant it as, as you said, uBlock is abandonware.

Re: Add-ons in 2017

#110

Post by Sylos » Fri, Nov 25, 2016, 12:41 AM UTC

tn123 wrote: post #74

detaro wrote: post #70

Earlier quoted context omitted.

Can/Do you want to comment on Mozilla's efforts to work with extension developers to bring everything needed to WebExtensions? While the promise sounds great, I would expect there are issues that make it not as easy in reality.

They are trying I guess, and may succeed for a bunch of use cases to bring what's required. But certainly not all. Even the add-ons that can be somewhat reasonably be ported will have to deal with limitations, and I think the quality of some of those ported add-ons will take a (major) hit. To elaborate: If you're doing "web stuff", toolbar buttons, and request stuff (adblocking etc), you'll probably be fine. If you'r…

It's still not clear to me whether you actually tried to work with the Mozilla devs or if this is still fueled from your initial (in my opinion rather rushed) statement and some form of false pride.

But yeah, I'd just like to say that in case you did not do your best to maybe get to a solution with the Mozilla devs, that I'd appreciate it, if you could try again.

I don't personally use your add-on, but I know that a lot of people do and I think that this initial discourse to get some of the APIs sorted out is rather important.

Even if you don't end up writing the extension, it'd be good to have reasonable APIs at least drafted. So that maybe someone can offer a half-assed Down Them All, which maybe is already good enough for some people, and then maybe that add-on's developer can continue working with Mozilla to get a proper API fully sorted.

You should also consider that Mozilla started out with this "webby" state from Chrome. Anything modifying the UI and so on still needs to be defined. Once they have some of the other UI-APIs worked out, it'll be easier for Mozilla to fit new libraries into there and then it'll also be easier for Mozilla to work with your API needs.