Live data from Hacker News

Add-ons in 2017

blog.mozilla.org

31–40 of 121 posts

Re: Add-ons in 2017

#31
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…

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

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 that Chrome has landed that same change a few months ago;

2/ ignore the add-on developers, improve Firefox immediately, but certainly break some add-ons, hence breaking the user experience of millions of users for no understandable reason.

As you can imagine, neither solution is good and everybody suffers from either.

WebExtensions condense all the instances of 1/ into a single point of time, hoping that we never again need to go through this painful dance.

Re: Add-ons in 2017

#32
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.

pentadactyl is co-developed by a member of the Firefox Add-ons core team [1]. I don't know what the plan is to port it to web extensions, but at least you can be sure the team is aware of it ;)

[1] https://github.com/5digits/dactyl/graphs/contributors

Re: Add-ons in 2017

#33
post #23
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…

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?

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.

Re: Add-ons in 2017

#34
post #21
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…

And, related to this, it makes it easier to move to Servo's layout code in the future, as it avoids Servo having to implement XUL and XBL.

Re: Add-ons in 2017

#35
post #27
post #25

Earlier quoted context omitted.

> 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…

The native messaging API is not useful for addon developers. They only cater to application developers that ship a companion addon to their application.

js-ctypes allowed an addon to access already-present native libs on the the host machine or bundled with the addon itself. Messaging only works if you can get users to install some external application in addition to your addon, which is a too-tall hurdle for small extensions.

From my perspective those barely comparable.

> 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.

You are taking requests to keep existing uses supported, mostly for big, already established addons. My concern extends beyond that. Simply by having access to internals anyone can currently develop novel uses, even if they initially do not have a userbase. Those can only be prototyped by access to internals. Someone might not even have an idea if they don't know an API exists that could be leveraged to do it.

In other words, "I can't let you do that, Dave" API design can stifle creativity.

And it also introduces a bias in favor of already entrenched extensions, which is less open than the current approach.

Re: Add-ons in 2017

#36
I'm a bit worried that some lesser known extensions will be unimplementable... Would the following still be implementable?

"Open in Browser", which allows ignoring "content-disposition:attachment" to display pdf/image/txt in browser rather than save to disk

"Android Text Reflow", which allows wrapping text to fit the screen on Android after zooming in on a web-page

"Status-4-Evar", which adds back the status bar at the bottom of firefox

Thanks!

Re: Add-ons in 2017

#37
post #6

The decline of XUL started around 2009. I spent months building a very complex app around XULRunner only to find out that Mozilla had no interest to support the technology in the future. So I decided to leave the platform and put my efforts on native and web and frankly it was a good decision. The WebExtensions API is no match to XUL and XPCOM but I only hope that now that we have Mozilla behind the technology we wil…

> I decided to leave the platform and put my efforts on native and web

For the sake of curiosity, did you create extensions as side-projects/startup ideas? Do people pay for extensions or are we talking about patreon funds here (Or startups like pocket whose extensions are ways to get more crowds).

Re: Add-ons in 2017

#38
post #6

The decline of XUL started around 2009. I spent months building a very complex app around XULRunner only to find out that Mozilla had no interest to support the technology in the future. So I decided to leave the platform and put my efforts on native and web and frankly it was a good decision. The WebExtensions API is no match to XUL and XPCOM but I only hope that now that we have Mozilla behind the technology we wil…

> I decided to leave the platform and put my efforts on native and web For the sake of curiosity, did you create extensions as side-projects/startup ideas? Do people pay for extensions or are we talking about patreon funds here (Or startups like pocket whose extensions are ways to get more crowds).

It was a desktop app that was based on top of XULRunner and yes it was for profit and people payed for it. I have no experience with selling extensions but I would imagine it is a very hard market to crack unless it is targeted towards enterprise customers.

Based on my experience, I can only advise not to base your entire business model on browser extensions as you will become dependent on platform moves (again unless enterprise).

Re: Add-ons in 2017

#39
post #19
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.

There is a reply on a review for the new release from September 1, 2016 which says:

"Just to clarify: We did not port it to the WebExtensions API, nor do we think it is possible to port it in any significant manner to the WebExtensions API..."

https://addons.mozilla.org/En-us/firefox/addon/downthemall/r...

Re: Add-ons in 2017

#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 the alternatives for me, used much less RAM, and rarely locked up. Since then, I've seen performance decline, RAM usage ramp up, and watched the browser lock up nearly once every hour. At this point, I'm probably just gonna go to Chrome. What's the point if Firefox is just gonna be a shitty clone?

Post reply on HN