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

21–30 of 121 posts

Re: Add-ons in 2017

#21

Post by Yoric »

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 was IE, but it makes the development of Firefox much less nimble than that of Chrome & co. So a new, less invasive and more future-proof API is sorely needed.

Re: Add-ons in 2017

#22

Post by nathancahill »

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…

Surely the burden is on the extension developers and not Mozilla?

Re: Add-ons in 2017

#23

Post by hucker »

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…

So, will extensions like pentadactyl or Tree Style Tabs be able to exist after "some point in 2017"? Ignoring rewrite time etc., will there be APIs available to do what they do today?

Re: Add-ons in 2017

#24

Post by vanni »

detaro wrote: post #19
oblio wrote: post #17

Earlier quoted context omitted.

That article is more than 1 year old. And Mozilla is going beyond the Chrome APIs, they are implementing shims and additional APIs to port almost everything over.

Is there a statement otherwise from DownThemAll? I haven't found anything, just references to that blog post.

At least they are releasing new versions yet:

http://www.downthemall.net/downthemall-3-0-5/

“After a rather long long time, with many new things to address such as Australis, e10s, limited time we could spend on the project, a little lack of motivation after mozilla required mostly pointless signatures and announced to kill XUL add-ons…” - Nils, September 2016

Re: Add-ons in 2017

#25

Post by the8472 »

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…

> is pretty much all of the internal APIs of Firefox,

But that's also what makes them more powerful than any other extension API.

If your box is airtight then there is no out-of-the-box thinking.

An almost trivial example: Internal APIs can inspect the current (as-enforced) sandboxing flags of an iframe. Which is not the same as the sandboxing HTML attributes on the frame, because those can be changed without effect after loading and also due to inheritance of sandboxing effects.

This tiny tiny tidbit is useful when making content-filtering decisions.

And it is just one among countless others.

Re: Add-ons in 2017

#26

Post by myfonj »

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 look at about:support page for "Multiprocess Windows" cell if it states 1/1 and does not mention "(Disabled by add-ons)" you are covered. You can try some about:config alterations [0] to force it if you are adventurous. In this case, it might be nice to install "Add-on Compatibility Reporter" [1] for tracking and sharing your findings.

[0] http://superuser.com/questions/1096974/how-to-check-if-multi... [1] https://addons.mozilla.org/en-US/firefox/addon/add-on-compat...

Re: Add-ons in 2017

#27

Post by Yoric »

the8472 wrote: post #25
Yoric wrote: post #21

Earlier quoted context omitted.

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…

> is pretty much all of the internal APIs of Firefox, But that's also what makes them more powerful than any other extension API. If your box is airtight then there is no out-of-the-box thinking. An almost trivial example: Internal APIs can inspect the current (as-enforced) sandboxing flags of an iframe. Which is not the same as the sandboxing HTML attributes on the frame, because those can be changed without effect…

Indeed, it's difficult to achieve a perfect balance here. That's one of the reasons the WebExtensions team has been very actively discussing with add-on developers to try and prioritize which APIs should be created/ported to WebExtensions.

I don't remember specific numbers, but I seem to remember that pretty much all the extension points that had been requested by add-on developers were at least somewhere on the TODO list of WebExtensions. I hope that by the end of 2017, they will all be available, with a much cleaner API than their XUL/XPCOM counterpart, better tests and much better survival chances.

Of course, some of the changes will require pretty drastic reimplementations by the developers. For instance, going from js-ctypes to the native bridge will require full reimplementation in a different programming language. On the upside, js-ctypes was really painful to use and the native bridge will let you use a much better language for the task. Say Rust :)

Re: Add-ons in 2017

#28

Post by Illniyar »

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.

Re: Add-ons in 2017

#29

Post by bitL »

If I can't use Ghostery, Blend In, No Resource Leak (or they are watered down), I see no use for Firefox. Please Mozilla, don't kill some of your biggest attractions! You copied UI from Chrome, now you are copying Add-Ons, why would anyone need to use your product then? Aren't you shooting into your own feet? When are you going to pull off Opera and just skin Chrome differently?

Re: Add-ons in 2017

#30

Post by smonff »

Firefox was supposed to be "slow" and they are trying to fix it radically with projects like e10s and Quantum.

If the browser is able to eat my RAM a bit less, I would be quite happy to have my add-ons off for some time.

Post reply on HN