But will Google allow this to happen, as it would strip them a huge selling point for Chrome?
Google already seems not to really care about extensions that much, as they don't work on mobile Chrome.
Browser Extensions Standard
21–30 of 82 posts
Re: Browser Extensions Standard
#22Earlier quoted context omitted.
The add-on ecosystem of Chrome currently dwarfs Firefoxes. Firefox extensions used to be more capable, but there's just more and certainly more NEW ones for Chrome. (I'm sure this was an important consideration for Mozilla as well - it reduced the supposed value of their "more powerful" XUL extension system, as in practice you can often find a Chrome extension to do what you want, but not a Firefox one)
But Firefox can already run WebExtensions (aka Chrome extensions). So how does this change anything?
It can.
But it can't keep XUL compatibility and do major overhauls of the browser.
If XUL compatibility doesn't even get you a clear advantage in the add-ons area, should it block modernizing the browser?
Firefox can't be the browser that people use only because they're stuck on it because they have extensions that changes how the browser works. Think about that for a bit.
Re: Browser Extensions Standard
#23Hm, 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…
> if web extensions become a standard, are they really even extensions?
They're browser extensions, not web extensions. If standardised, then arguably they will be a native part of the web stack, yes.
> strictly limits extensions to things the browser vendors explicitly did conceive of, and stamped their approval on
That's the situation today anyway. The new standard won't change that. Browser vendors may opt to follow the new extensions standard as a 'baseline' feature set, and provide further non-standard options on top of it.
Most extension APIs follow common patterns, and this standard paves those cowpaths. The standard needn't predict all future extension needs to be useful today. For comparison, the DOM is a standard, but individual browser vendors still experiment with their own custom DOM features, and these experiments sometimes get 'merged in' to the standard. Meanwhile, authors benefit from having a well defined set of features that work across platforms. Standardisation doesn't need to be final or absolute to be useful.
Re: Browser Extensions Standard
#24Earlier quoted context omitted.
But Firefox can already run WebExtensions (aka Chrome extensions). So how does this change anything?
It can. But it can't keep XUL compatibility and do major overhauls of the browser. If XUL compatibility doesn't even get you a clear advantage in the add-ons area, should it block modernizing the browser? Firefox can't be the browser that people use only because they're stuck on it because they have extensions that changes how the browser works. Think about that for a bit.
I know all about the issues with Firefox, the new WebExtensions and how the "old" XUL extensions which let you do "anything" are being phased out.
I just don't see how any of that is relevant to the original comment I replied to:
> But will Google allow this to happen, as it would strip them a huge selling point for Chrome?
In what way would standardizing WebExtensions, which are already supported by all modern browsers (sans Safari), strip Chrome of selling points?
Why should Google have to "allow" this?
Re: Browser Extensions Standard
#25The only problem which Mozilla didn't think about or hasn't given much value to is the huge number of add-ons that are going to die or just stop working when they completely switch to WebExtensions (as there's just no replacement to the previous API in them). One of the Firefox's USPs was its addons which could modify the browser behavior and UI in any manner. It's all going to go, and Mozilla is moving closer to bec…
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.
Re: Browser Extensions Standard
#26Earlier quoted context omitted.
Not sure what you mean by this, but this (like most modern web standards, and I'm not even sure of the modern part) is just documenting what the implementations are already doing . Mozilla and Microsoft are specifically re-implementing the Chrome Extensions API, and documenting it.
Eating a broom is a German saying: «Eher fress ich einen Besen...!».
Thank you! I was just about to ask about the origins of that phrase (which I've never heard before).
Re: Browser Extensions Standard
#27Hm, 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…
> if web extensions become a standard, are they really even extensions? They're browser extensions, not web extensions. If standardised, then arguably they will be a native part of the web stack, yes. > strictly limits extensions to things the browser vendors explicitly did conceive of, and stamped their approval on That's the situation today anyway. The new standard won't change that. Browser vendors may opt to foll…
"They're browser extensions, not web extensions"
The vendors are using both terms. See, for example, the text at the end of this url, and both terms in the text.
Re: Browser Extensions Standard
#28As a developer, I'd really like if I could publish an extension as a single archive file and have users load it into whatever (compliant) browser they like - however, the standard doesn't seem to actually support this. When it comes to packaging, there is nothing more than a vague acknowledgment:
Browser extensions MAY be distributed and subsequently loaded as individual files or via a container, such as a .zip archive. Regardless of the packaging format, these containers MUST contain the following: [manifest.json, Necessary JavaScript files (.js)] [...]
Browser vendors MAY require that extension packages include a digital signature. The signature MAY indicate the source of the extension, such as a distribution store or the extension's publisher. This aspect of packaging varies by browser, and browser implementers MAY enforce different requirements.
I guess that's a concesson to all the politics surrounding app stores, but it's disappointing nevertheless.
Re: Browser Extensions Standard
#29Does 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 made an extension to appease a slight reddit addiction: "What's new reddit?" https://github.com/mrspeaker/whats-new-reddit/ it highlights updates and auto-refreshes things.
I wrote it for Firefox, and then I wondered what it would take to port it to Chrome. The answer was "nothing really" - it worked out of the box for the main functionality. I had to do a small wrapper over loading settings, but having done a million extensions in the past, I was pretty surprised to see it load straight into a different browser!
Re: Browser Extensions Standard
#30Does 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]
Safari is moving away from the 'pure JS, in-browser-process' extension mechanism entirely and I doubt the Chrome people are prepared to be saddled with a standards process for their own API they are still actively developing. As a practical matter, this standard/group seem rather pointless.