Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Add-ons in 2017

blog.mozilla.org

Post reply on HN
Print view View original

111–120 of 121 posts

Re: Add-ons in 2017

#111

Post by tn123 »

Sylos wrote: post #106
tn123 wrote: post #79

Earlier quoted context omitted.

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…

I get this conclusion from over a decade of add-on development, and many years of volunteering my time to/for mozilla in various capacities incl helping other add-on developers, reviewing add-ons for AMO, fixing bugs within Firefox itself, during which I became quite familiar with the code base and development process of Firefox.

PS: As to maintaining XUL vs WebExtensions API, they always maintained XUL/XPCOM themselves because that's what Firefox itself uses, meaning the entirety of Firefox developers "maintains" that "API". They regularly broke stuff for add-on developers, which was sometimes annoying, sometimes avoidable, and other times just necessary.

Some add-on developers learned to adept to that, other add-on developers switched to the add-on SDK (which like WebExtensions is a limited API, just not chrome compatible) if it was feasible, and a lot of developers will switch to the WebExtensions API if feasible in the future or even now.

Re: Add-ons in 2017

#112

Post by tn123 »

hackuser wrote: post #102
tn123 wrote: post #79

Earlier quoted context omitted.

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…

From Nils Maier, developer of some of the most complex and most popular extensions, DownThemAll! (+ MinTrayR): Read my comments

That comment by Giorgio (nice guy btw, shared a room with him on at a couple of mozilla events) is over a year old by now and rather optimistic. So far, nothing of that happened, nor will it ever happened at a scale that actually accommodates most add-on developers.

Re: Add-ons in 2017

#113

Post by tn123 »

Sylos wrote: post #110
tn123 wrote: post #74

Earlier quoted context omitted.

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…

I volunteered massive amounts of my time for mozilla for more than a decade now, not only developing. I do not consider my previous statement rushed, but a realistic prediction based in a decent foundation of experience and knowledge, and - rather unfortunately - so far I am right and there is no indication that that's about to change.

I'd really like to share your optimism here, but really, knowing what I know, I just cannot.

Re: Add-ons in 2017

#114

Post by threepipeproblm »

People inside institutions tend to have trouble admitting when they're wrong. They basically don't do it. So I fear for the worst with this.

Could be some kind of effort to fork the code and have users who care about Firefox rally around a non-hobbled version?

Re: Add-ons in 2017

#115

Post by aq3cn »

anotheryou wrote: post #12

Old or complex add-ons are what keep me with firefox. Will switch to qutebrowser¹ and probably chrome as my backup for what the cutie can't handle. ¹keyboard goodness: https://github.com/The-Compiler/qutebrowser

You can also try Vivaldi when something does not work in qutebrowser as it has support for single key keyboard shortcut s. I recently voted for native vim mode in Vivaldi reddit feature request thread. Worth checking out.

Re: Add-ons in 2017

#116

Post by Illniyar »

tversteeg wrote: post #91
Illniyar wrote: post #28

As always, the only question for me is whether tree style tabs is going to work with WebExtenstions. If not, then say hello to people staying with firefox 56 for years.

There is a native vertical tab feature in Test Pilot, the downside is that it doesn't support nesting (yet?).

What is Test Pilot? Another release channel?

Re: Add-ons in 2017

#117

Post by nachtigall »

teh wrote: post #97
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.

I just migrated a complex extension and with Firefox 52 most features are there. It was a bit painful but the new API is much better IMO. Also, we now have one code base less to maintain.

Interesting. Mind sharing a link to your add-on?

Re: Add-ons in 2017

#118

Post by hucker »

dri_ft wrote: post #73
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.

Didn't Pentadactyl stop working a while ago? For a while I was trying to keep it working, making the necessary changes on every firefox update, but eventually it got too much for me and I switched over to VimFX. At first I didn't think it would be satisfactory, but it actually is a quite good 80% solution. What seemed to be a weakness - the fact that it doesn't aggressively change how the browser works - now seems li…

Apart from having to manually up the maxVersion every now and then (and rebuilding from source), pentadactyl has Just Worked™ for me.

Re: Add-ons in 2017

#119

Post by myfonj »

majewsky wrote: post #104
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…

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.

Oh, thanks for pointing this out, I really mixed multi-process and WebExtensions and diminished main XUL problem (which I oversimplified for myself as "just problem of settings pages to be rewritten to HTML" what is really wrong [0]).

As I understand it WebExtension is inherently multi-process compatible so (to answer question below) the only extensions we know today will work next year from arewee10syet.com are those marked as "compatible-webextension".

[0] Most of extensions I'm used to alters chrome visually or functionally: calls external applications, changes hotkeys, so almost none of them are XUL-free. But I still hope / believe Mozilla is not that insane and will achieve consensus keeping the most important features for extensions authors available in the end.

Re: Add-ons in 2017

#120

Post by hackuser »

tn123 wrote: post #112
hackuser wrote: post #102

Earlier quoted context omitted.

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…

From Nils Maier, developer of some of the most complex and most popular extensions, DownThemAll! (+ MinTrayR): Read my comments That comment by Giorgio (nice guy btw, shared a room with him on at a couple of mozilla events) is over a year old by now and rather optimistic. So far, nothing of that happened, nor will it ever happened at a scale that actually accommodates most add-on developers.

> So far, nothing of that happened

He wrote that it was already happening a year ago: 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

I'm not an add-on developer but I've read about it happening in other places too, and I know for a fact that Giorgio is working on Firefox WebExtensions issues in Bugzilla.

Post reply on HN