31–40 of 82 posts
What value does this really provide? The times that I've gotten into browser extensions were really working with features that are unique to the given browser.
I can't wait to port my extension to Firefox. Firefox is seeming like a more and more viable option to Chrome.
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…
I recently tried to port my Chrome extension to Safari (which I actually use as my main browser) and failed because of the lack of many necessary calls like a check for idle or if the app is in focus.
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 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 mill…
This standard seems to be intended to formalize a lot of the stuff Chrome does so that other browsers can follow a common _standard_ instead of just being stuck imitating what Chrome does.
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.
I find unfortunate to see such trivialization of dev work from outside. They had to deal with years of legacy code piling up, and this was seriously impeding the modernization of Firefox.
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.
Which "they" did, and are. Some APIs are more amenable to such replacement than others. For example, APIs that allow you to modify any part of the browser UI in an arbitrary way are not so amenable _and_ have the problem of breaking any time the internal structure of the UI changes. Which has, in the past, prevented improvements to the internal structure of the UI...
It's really easy to see only one side of this (the downside of extensions breaking, or the upside of not having your implementation severely constrained by extensions that keep depending on internal details they shouldn't depend on). But there are in fact people who've thought long and hard about both sides of this.
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…
The main difference is that the user installs an extension, which possibly modifies the behavior of the browser for all websites. A traditional web API only takes effect if the page that the user visits makes use of that API.
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…
As 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 archi…