What is the goal of this group since the current WebExtensions standard is already supported by almost every major web browser? If seems their goal is already complete.
Ok… but the following topics in your list have nothing to do with an API specification, which is what they say their goals is on the Goals section:
>
“A few UI differences between chrome's extension popup and firefox's one means you'll need to potentially leave out features for one browser.
- UX differences between browsers means you'll need to write extra code, and maybe a few extra tutorials.
- Huge huge difference between publishing on chrome vs on firefox
- Safari requires xcode, and therefore macos to publish”
Bottom line is I don’t think there is going to be an api standard around “distribution and publishing areas”
Plus, you probably still need a Mac or a virtualized Mac (for automated tests, for example) because you’ll want to test your extension with Safari to ensure it works correctly.
I don’t get your comment. You just confirmed that, indeed, you need a specific computer to publish Safari extension, which isn’t the case for Firefox and Chrome extensions.
It is a limitation and it’s completely unnecessary for the end user.
If they’re so lazy to have a extensions-specific store they could at least offer an automatic wrapper that they run before publishing. I should not need XCode anywhere in my build to publish web extensions.
But you need Safari to test the extension and Safari only has these extensions on a Mac? This is Apple’s way of avoiding their store getting cluttered with extensions that haven’t been tested to work on Safari. And yes, it also encourages developers to buy Macs. It can do both…
Can you explain what you mean by “literal dumpster fire” because this doesn’t align with my own experience. I’ve used it for purchasing a number of apps recently and I saw nothing eyebrow-raising. So long as the app you want has been uploaded to the store, it works perfectly fine.
And before anyone claims u can just buy time on a cloud Mac... The cost for these and requirement from Apple for a min. period of 24 hours rental (something to do with Mac stadium?) mean you're funneled towards making the $2000 "investment" in a iDevice.
Chrome published the WebExtensions API, not Mozilla. Whether or not it’s a standard is another question, you could call it a defacto standard, but Chrome definitely implemented the api that they published.
Except Apple who don’t have the incentive of browser advertising and are currently selling privacy as one benefit of choosing their hardware (and by extension their software and browser [safari])
Mozilla make money from Google deals and so have outside incentives to not rock the boat too hard on this detail.
As always its about control. Its a fight against general computing.
The goal is deprecation of "remote code" execution, where "remote" means remote to Vendor, but local to user, aka anything not shipped and signed by the extension store.
- webextensions specific storage apis to return promises but chrome still needs callbacks
- A few UI differences between chrome's extension popup and firefox's one means you'll need to potentially leave out features for one browser.
- csp policies differs between chrome and firefox(and cors too I think)
- UX differences between browsers means you'll need to write extra code, and maybe a few extra tutorials.
- Difference between how permissions are interpreted on different browsers
- Huge huge difference between publishing on chrome vs on firefox
- Safari requires xcode, and therefore macos to publish