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

Browser Extensions Standard

browserext.github.io

Post reply on HN
Print view View original

51–60 of 82 posts

Re: Browser Extensions Standard

#51

Post by Manishearth »

OliverJones wrote: post #20
OliverJones wrote: post #17

Does anybody know whether the Google Chrome / Chromium team and the Mozilla team are squarely behind this standardization effort? What about the Apple Safari team? There's only one rep from Google in the community group. There don't seem to be any from Apple. [1990s paranoia mode] this could be another Microsoft effort to embrace and suffocate [/1990s paranoia mode]

I've been working on web extensions for multiple browsers lately. Chrome and Firefox have workable ecosystems and accept more or less the same code, but package it differently. Edge accepts almost the same code, but they had to change the "chrome" namespace to "browser". I suppose it was a question of pride. Also, Edge doesn't have a workable way to publish and to inline-install web extensions. Safari accepts similar…

> but they had to change the "chrome" namespace to "browser"

It's weird, because Firefox internally has had the "chrome" namespace long before Google Chrome existed.

In browser terminology the browser "chrome" is the stuff that's outside the browser engine -- the stuff that doesn't handle loading/laying out/rendering/javascripting a page. I.e. the tab strip, URL bar, bookmarks, context menus, settings, etc.

IIRC (very unsure of this, but have heard it from different non-google sources) the name "Google Chrome" is actually a joke on this because it had the least chrome amongst browsers of the time (remember the toolbar and status bar?)

Re: Browser Extensions Standard

#52

Post by rodorgas »

avaer wrote: post #5

Hm, if web extensions become a standard, are they really even extensions? Isn't that just new web APIs with tweaked security parameters? This is great for security and all, but browser extensions were borne out of the idea that you wanted your browser to do things that the browser vendor didn't want, or didn't even conceive of. Having it be a standard adds security but strictly limits extensions to things the browser…

That's a common set of features every browser should support. Because doesn't make sense to have various techniques to achieve simple behaviors like a toolbar button.

Browsers can add their own brand new features, the specs are just for the minimum.

Re: Browser Extensions Standard

#53

Post by [deleted] »

avaer wrote: post #5

Hm, if web extensions become a standard, are they really even extensions? Isn't that just new web APIs with tweaked security parameters? This is great for security and all, but browser extensions were borne out of the idea that you wanted your browser to do things that the browser vendor didn't want, or didn't even conceive of. Having it be a standard adds security but strictly limits extensions to things the browser…

[deleted]

Re: Browser Extensions Standard

#54

Post by reitanqild »

piyush_soni wrote: post #25
gcp wrote: post #16

Earlier quoted context omitted.

Mozilla has given this a lot of thought, and realized it is extremely valuable . But the value does not dwarf the downsides. XUL extensions would block most of the Servo work, as an obvious example. You can't rely on the browser internals if those are changing underneath you.

Had they given it enough thought, they'd have pushed for replacement of XUL APIs in WebExtensions in a non-blocking way, for example. But they found killing all of the valuable add-ons of years worth of work of so many developers justified.

Had they given it enough thought, they'd have pushed for replacement of XUL APIs in WebExtensions in a non-blocking way...

They have. It is not finished yet but work is underway.

I also learnes from last(?) discussion about Firefox here on HN that there is even a developer extension that you can install on nightly that will let you create your own extension api.

This is useful 1. if you are a developer that is happy with using nightly and making/copying extensions on top of your own api 2. even more useful as you can sketch out api ideas in js without touching the Firefox C++ codebase.

BTW: Manishearth who is acrive in this discussion often shares knowledge from the inside of Mozilla. If anyone are really interested then reading his comment history might be interesting.

Re: Browser Extensions Standard

#55

Post by kbrosnan »

Manishearth wrote: post #49
pimterry wrote: post #2

Finally! WebExtensions ( https://developer.mozilla.org/en-US/Add-ons/WebExtensions ) have slowly been becoming an adhoc standard for a little while now, but with a few tricky small differences here and there between browsers (e.g. https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Ch... ). So far it's just been Firefox and Edge slowly building a close approximation of Chrome's existing API, but a proper standa…

I'm not very involved, but on top of the Chrome base API both Firefox and Edge have a bunch of additional APIs IIRC (I think Firefox supports all of the Chrome APIs but I'm not sure). The intent is to have the same manifest format so basic extensions work everywhere, but extensions can use browser-specific APIs that fit within the same general framework too.

One of the big differences is that Firefox and Edge do not support any of the deprecated APIs.

Re: Browser Extensions Standard

#56

Post by notheguyouthink »

avaer wrote: post #5

Hm, if web extensions become a standard, are they really even extensions? Isn't that just new web APIs with tweaked security parameters? This is great for security and all, but browser extensions were borne out of the idea that you wanted your browser to do things that the browser vendor didn't want, or didn't even conceive of. Having it be a standard adds security but strictly limits extensions to things the browser…

Another perspective would be that a standardized browser extension api means you're not locked into browsers via "essential" extensions. Though, while I do like removing locking, I'm not sure if that is a bigger concern than what you cite.

Re: Browser Extensions Standard

#57

Post by carussell »

Yoric wrote: post #44
mekkkkkk wrote: post #40

It would be interesting to have a browser where every part except the engine is an extension. I.e. hotkeys, address field, bookmarks and so on being standardized, replaceble extensions, run in a chromeless window. An infinitely hackable experience. Prepackaged bundles could ship as discreet browsers, for the less techy user.

Well, that sounds like the historical Firefox. If you look at the source code of Firefox, just about everything except Gecko is a XUL add-on. Worked like a charm for the first 10 years, not so much afterwards because it became a maintenance nightmare. That's actually the main reason for which Firefox is moving away from XUL add-ons and towards more restricted WebExtensions.

> If you look at the source code of Firefox, just about everything except Gecko is a XUL add-on

That's not really true at all. Most of the Firefox UI was written in JS (and XUL and XBL), but not as add-ons.

It would have been great if it were true, because not only do you get the reconfigurability the parent commenter writes about, but there are even better advantages: it would also have meant the Firefox team themselves would have had to confront the poor APIs exposed to extension authors and the poor practices about breaking things. The reality is everyone just touched browser.js (or what have you) to make it do what they wanted.† Had that not been the case, the deprecation of old-style toolkit add-ons might have happened long ago and a good replacement created. What happened instead is the worst from both ends: a sickly add-ons ecosystem built on top of fragile XUL-based extensions hobbled along for years, and now that they are obsoleted, they are given a replacement that is decidedly not good.

When Robcee announced he'd gotten the imprimatur to ship devtools with Firefox, I made an impassioned plea for it to be developed and shipped it as a built-in add-on, for exactly these reasons, and because it would have allowed faster development iteration and provided an easier contribution path (no need to ever waste hours rebuilding nightly, or asking for the same from a casual contributor who wants to submit a patch but doesn't work for a manager with an @mozilla.com address). No dice.

† Not to mention tons of XPCOM junk not related to rendering or parsing or the JS runtime that was nevertheless implemented in C++ and would need updates to the core if ever wanting to anything non-trivial.

Re: Browser Extensions Standard

#58

Post by greenhouse_gas »

avaer wrote: post #5

Hm, if web extensions become a standard, are they really even extensions? Isn't that just new web APIs with tweaked security parameters? This is great for security and all, but browser extensions were borne out of the idea that you wanted your browser to do things that the browser vendor didn't want, or didn't even conceive of. Having it be a standard adds security but strictly limits extensions to things the browser…

In general, if your software supports plugins, you can:

1. Have plugins with ultimate power (meaning that plugins can change everything, no encapsulation) 2. Stable API/ABI (meaning that plugins written for version 1 will work with version 2) 3. A refactorable code base.

You can pick only two out of three.

Traditionally, Firefox chose 1 and 2, and for stuck without multiprocess support for years (causing it to have worse performance and security), and now wants to move to 2 and 3.

Incidentally, I suspect that's _one_ of the reasons Linux doesn't have a stable Kernel ABI - they chose 1 and 3.

Re: Browser Extensions Standard

#59

Post by syshum »

pimterry wrote: post #2

Finally! WebExtensions ( https://developer.mozilla.org/en-US/Add-ons/WebExtensions ) have slowly been becoming an adhoc standard for a little while now, but with a few tricky small differences here and there between browsers (e.g. https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Ch... ). So far it's just been Firefox and Edge slowly building a close approximation of Chrome's existing API, but a proper standa…

Yes, Finally, all browser will be chrome clones, just what we need...

Sad times indeed, when people celebrate mono-culture and the lack of options...

W3C is leading effort to kill the Open Web and everyone is just clapping long... EME, Browser Extensions, what will be the next thing W3C will sell to its google overlords?

Re: Browser Extensions Standard

#60

Post by Slackwise »

Manishearth wrote: post #51
OliverJones wrote: post #20

Earlier quoted context omitted.

I've been working on web extensions for multiple browsers lately. Chrome and Firefox have workable ecosystems and accept more or less the same code, but package it differently. Edge accepts almost the same code, but they had to change the "chrome" namespace to "browser". I suppose it was a question of pride. Also, Edge doesn't have a workable way to publish and to inline-install web extensions. Safari accepts similar…

> but they had to change the "chrome" namespace to "browser" It's weird, because Firefox internally has had the "chrome" namespace long before Google Chrome existed . In browser terminology the browser "chrome" is the stuff that's outside the browser engine -- the stuff that doesn't handle loading/laying out/rendering/javascripting a page. I.e. the tab strip, URL bar, bookmarks, context menus, settings, etc. IIRC (ve…

> IIRC (very unsure of this, but have heard it from different non-google sources) the name "Google Chrome" is actually a joke on this because it had the least chrome amongst browsers of the time (remember the toolbar and status bar?)

Well, that and it was Google.com's "chrome".

Post reply on HN