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

41–50 of 121 posts

Re: Add-ons in 2017

#41

Post by [deleted] »

Yoric wrote: post #31
nathancahill wrote: post #22

Earlier quoted context omitted.

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

[deleted]

Re: Add-ons in 2017

#43

Post by ethbro »

Yoric wrote: post #31
nathancahill wrote: post #22

Earlier quoted context omitted.

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

Is there a reason a both approach wasn't pursued with the current method being marked unsafe but still available for use? A la Rust mixing code but having to explicitly mark unsafe bits.

For reasons listed in other comments above, the "we will expand WebExtensions API coverage based on current add-on needs" scares the shit out of me.

I'm having visions of why I quit using Chrome because there was some download UX that could not be altered, and the default Google "one true way" of doing it irked the hell out of me.

Re: Add-ons in 2017

#45

Post by dbalan »

Slightly OT: There is another problem that most people seems to miss. Add-ons in their current form in ff are tightly coupled to the browser to the point that it's the browser itself. In the modern web, the browser knows too much about you, and so does the add-on, and it's not unheard of them to explore it[1]

How does that free webpage to PDF converter add-on make money? By selling your web history of course.

[1] https://www.google.de/amp/thehackernews.com/2016/11/web-of-t...

EDIT: added OT tag

Re: Add-ons in 2017

#46

Post by mgbmtl »

speps wrote: post #9

Anyone knows about the fate of SeaMonkey? It's still based on XUL as far as I know and supports a lot of existing Firefox extensions.

There are constant references on forums to how they want to move away from XUL, for both Firefox and Thunderbird. XUL works, but I feel like very people are able to improve the guts of XUL, and that can be a huge risk for the future of the project. Pale Moon seems to be the main contender willing to maintain XUL, but presumably not improve it (changes to XUL can break extensions).

As someone working on another free software project with an aging code base, we see this debate all the time: limited funds, limited interest to maintain the old core, but users rely on it. However, users also want performance improvements, more reliability, new features... not to mention what do you do when security issues pop up. At some point you need to cut your losses and find a model easier to maintain.

Re: Add-ons in 2017

#47

Post by kigbljnkgk »

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…

Try waterfox

Re: Add-ons in 2017

#48

Post by jhasse »

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…

What do you mean by "full themes"? There are many different themes available for Firefox which still work with v50.

Re: Add-ons in 2017

#49

Post by jhasse »

dbalan wrote: post #45

Slightly OT: There is another problem that most people seems to miss. Add-ons in their current form in ff are tightly coupled to the browser to the point that it's the browser itself. In the modern web, the browser knows too much about you, and so does the add-on, and it's not unheard of them to explore it[1] How does that free webpage to PDF converter add-on make money? By selling your web history of course. [1] htt…

Web history is also available to WebExtensions, so I don't see how this is relevant to people missing XUL/SDK addons?

Re: Add-ons in 2017

#50

Post by Yoric »

the8472 wrote: post #35
Yoric wrote: post #27

Earlier quoted context omitted.

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…

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

I haven't checked, but I seem to remember that you can provide a platform-specific binary as part of an add-on, spawn it from WebExtensions and then communicate with it through the native bridge. Building/shipping one binary per platform is annoying, but the rest is infinitely better than using js-ctypes. I should know, I've been one of the first users of js-ctypes and I still shudder at the thought :)

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

True. On the other hand, this is the kind of paradigm shift that was implemented by operating systems ~20 years ago (more in the case of Unix) and so far, improving the safety and security of operating systems has generally played in favor of users and creativity, not against them.

This doesn't mean that there is no space for lower level, MS-DOS/Apple II-style hacking – I'm doing exactly that these days. But still, separating both sounds like a good idea to me. YMMV.

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

Good point. I seem to remember discussions about how to have an "unsafe" extension mechanism that would make it easier to experiment with non-standard APIs. I haven't checked myself, but I believe that this mechanism has been published, as an extension called "the WebExtension Extension" or something like that.

Post reply on HN