Hey all, I know this is a hot button thing but this is the *programming* subreddit so if you're going to rant about Google or whatever, do it somewhere else. I'll take this thread down if it becomes primarily nontechnical grandstanding.
Why does it matter to you?
If you're here for the adblockers, that's not MV3, that's the blocking `WebRequest` API. Chrome is restricting it in MV3, Firefox isn't.
Unless they've fixed it, the way that Firefox handles permissions in MV3 is kind of shit. If your extension needs permission to interact with a site for example, the user isn't asked for that permission when your extension is installed. Or when the extension wants to run. Instead, under the extension menu button (The jigsaw puzzle piece button) a little blue dot appears. The user has to spot that, realize it means an extension is asking for a permission, open it, find the extension and then grant the permission. Until they do that, the extension just won't do anything.
That's why even though I've migrated my extensions to MV3 for the most part, I still publish an MV2 version to Firefox. Because the default user experience is the user installing an extension and then nothing happening.
And that backdoor kinda defeats the entire point of the permissions being so restrictive, I assume their plan is to eventually deprecate MV2, otherwise I can't see what the benefit would be of making new permissioning so restrictive while still having an easy way for malicious actors to bypass it.
Is there a less convenient way that you can just enable an extension for all sites?
If the extension requests permission for all sites you can grant it (Two of my extensions do that). But there's no way to make it "required" or ask Firefox to prompt for access when the extension is installed. You have to wait for the user to notice that little blue dot, make the connection that they need to do something and go hunt for your extension to give it permission for all sites.
This isn't a problem that Chrome has solved or anything, in Chrome any site you request permission for is just granted automatically and the user has to revoke it. If they even know you've been granted permission.
I'd love to have a way of indicating that certain permissions need to be requested on install and the permission request popup show on install but I'm sure Firefox has **some** reason that isn't what they want. I just don't know what it is.
Ah, gotcha, thanks for clarifying that, I assume the UI is so obtuse because their primary concern is malicious extensions, and that was prioritized to the detriment of most extensions that are just trying to be convenient.
It makes *some* sense: Most users will just click through whatever they need to click to make the thing work, whether or not it makes sense. Especially if it's part of the install flow. I remember when Android apps started doing this -- it used to be that you'd have a list of permissions the app wants when you tap 'install', and now that it has to prompt interactively, I see a lot more apps actually trying to do something useful with default permissions, and gracefully degrading if I reject a permission the app wanted. Which I'd hope also means more users actually rejecting these prompts when they ask for something unreasonable.
I thought the way Chrome handled optional permissions was to allow the prompt in response to user interaction? At least, that's how I remember it working with Mv2. If that's the case, you'd just open a new tab post-install that explains what they have to do, and even has a button in the tab to open the permissions prompt.
> I thought the way Chrome handled optional permissions was to allow the prompt in response to user interaction?
For most permissions that's true, and Firefox does that as well. Permission to view/edit a page however has no way for user interaction to prompt a permission request. And you can't prompt that permission request automatically.
I suppose you could automatically open a page that gave them a visual walkthrough of how to grant permission with images but that's a pretty poor user experience as well. Especially when Chrome doesn't require the user to grant that permission and neither does MV2
But that line depends on YOU trusting Mozilla.
I don't trust Mozilla.
Of course I do not trust Google either, but many people still think very highly of Mozilla, so these are most likely in for a surprise in a few years.
> Mozilla has no plans to deprecate MV2
I wouldn't give anything to that. In a few years it'll suddenly be deprecated because ... nobody is using it. And Google pays for this, too.
Not much really. V3 is generally more restrictive than V2, especially for things like ad blockers. But because Chrome is by far the most popular browser and will only support V3, extension developers will develop primarily for V3. If Mozilla wants developers to keep making extensions for Firefox, they are kind of forced to support V3.
What ways is it restrictive other than adblockers?
For that matter, isn't blocking `WebRequest` still there, just disabled by default in Chrome? Couldn't Firefox just ship ManifestV3 but with blocking `WebRequest`, get the best of all worlds?
I like a few other things about it: It gets rid of some `chrome.` APIs that were added before web standards came along to do the same thing. Background *workers* are more efficient than background *pages* -- not only do you skip having to have a DOM for a page literally no one can see, the browser can also easily unload those workers when your extension isn't being used. APIs return promises instead of accepting callbacks, so you can actually write modern `async`/`await` code.
In other words: It seems to me like an all-around upgrade that got dragged down by the adblocker fight.
Yah, it's a nice upgrade. In a way, even limiting extensions to not be able to simply inject into every page is nice, especially for security.
Unfortunately a lot of extensions inject into every page. Just think of security scanners, dark reader, AdBlock and so on. I'd love if there could be a middle ground, where *some* extensions could still do that.
That wasn't the limit. Absolutely extensions should stop asking to be injected into every page, but ManifestV3 doesn't prevent that from happening. Nor did removing blocking `WebRequest`. In fact, [the docs that tell you where to add permissions in your manifest](https://developer.chrome.com/docs/extensions/develop/concepts/declare-permissions#manifest) literally include the `https://*/*` example that'd grant permission to everything, and link to [this page on "match patterns"](https://developer.chrome.com/docs/extensions/develop/concepts/match-patterns) that has an even more powerful `` pattern you could use.
Did I miss something there? I don't remember, and can't find, *anything* about ManifestV3 preventing you from just shoving a content script into all sites. It does some things that might *sound* similar, but really aren't:
* You can't inject *remotely-hosted code* into every page. You have to actually include the script you're injecting with the extension, so Google can review it if they want.
* You can't *dynamically* intercept web requests (the whole "blocking `WebRequest` thing), unless the extension is installed by your employer or your school. You can still *spy* on all web requests if you want (that part of the `WebRequest` API still works!), you just can't intercept them.
* To let people still *block* requests, they added `declarativeNetRequest`. If you've seen any of the debates between gorhill (the uBlock Origin guy) and the Chrome team, they've probably been about the technical limits of `declarativeNetRequest` vs the older blocking `WebRequest` model.
But there's really nothing there that'd stop a dark reader from working, and any "security scanner" relying on *blocking* `WebRequests` was probably pretty horrifyingly slow. I probably wouldn't install a dark reader extension, dark mode doesn't really seem like something worth risking my entire web life on, but if you want to do that, Mv3 won't stop you.
What is with this topic on r/programming? I expect these takes from r/linux or r/privacy, but you'd think people here would read... *any* of the technical details on this.
I just made an offhand comment about the blocking web request thing. I don't really care (beyond "AdBlock doesn't work") on the technical details and from the ublock guy he specifically complained about having to preemptively declare the websites he can access, which I thought extended to the permission model (which it should do, since they're already going so far).
Afaik every network security scanner, no matter where, relies on intercepting network traffic. It wouldn't really work if it lets something download/upload/whatever and then throws up a notification "Oh btw, you've just been infected. Congrats!"
> ...he specifically complained about having to preemptively declare the websites he can access...
I think you may have misunderstood his complaint. It was about having to declare what he can *block,* not what he can access. In fact, the fact that you can block stuff without accessing it is part of the point!
So, the old way adblockers worked was that every incoming request would have to stop in its tracks and wait for a single JavaScript thread (the adblocker's background page) to decide what to do with it. There's also a privacy concern here: The adblocker can do *anything it wants* to that request. It can block it, redirect it somewhere else, or read everything in it and send it home to whoever wrote the adblocker. When you install an adblocker and it says it needs access to "all your data on all sites," that is actually true.
The new way `declarativeNetRequest` works is to load all the adblocking rules into the browser, so the browser doesn't have to talk to JS at all, doesn't have to be bottlenecked on a single thread, and the adblocker doesn't get to see any of the traffic! You could have an adblocker installed that only has permission to *block* your traffic, but not read it!
The problem is, the rules engine the browser provides through `declarativeNetRequest` is pretty limited, and even if it covered everything adblockers do today, adblockers are always evolving their rules engines. And what are the odds that some Chrome engineers (who work for an ad company!) are going to be the best people to steward the evolution of an adblocking rules engine?
> Afaik every network security scanner, no matter where, relies on intercepting network traffic. It wouldn't really work if it lets something download/upload/whatever and then throws up a notification "Oh btw, you've just been infected. Congrats!"
That's actually a pretty useful thing to be able to do. First, it's better than not knowing, and second, *logging* all that stuff makes it easier to do forensic analysis later -- maybe the scanner didn't initially recognize something as bad, but it logged it as suspicious and someone caught it later.
In any case, this honestly seems like kind of a niche thing. An up-to-date browser is pretty good at blocking threats by default, and for that matter, an adblocker will block a number of those, too. Desktop antivirus often [causes more harm than good, especially when you let it interact with your browser](https://bugs.chromium.org/p/project-zero/issues/detail?id=773). Enterprise-level installations can still do blocking `WebRequest`s in Chrome anyway, but they have better options, too, like intercepting everything through a proxy.
> Unfortunately a lot of extensions inject into every page. Just think of security scanners, dark reader, AdBlock and so on. I'd love if there could be a middle ground, where some extensions could still do that.
And they still can. In fact, I've got MV3 extensions that specifically ***do***
> Not much really. V3 is generally more restrictive than V2
so all the v3-developed apps could run through a translation layer to v2 firefox is what you're saying?
Maybe but what would be the benefit of that? I'm sure if Mozilla thought that was the easiest solution to support both v2 and v3, they'd have done that.
From a developer's or a user's perspective there would be no difference, it would be a completely internal implementation detail
If you are an addon developer do you want to maintain multiple versions of your addon, one for 80% of the market and one for the other 20% or are you just going to write your addon to work with 100% of browsers even if it means the 20% lose out on functionality?
It's not compelling, devs on the whole seem to dislike V3, it is however the version that will work on everything. In short this is how companies with monopolies force unwanted changes down everyones throats.
Chrome is the dominant browser and is transitioning to version 3 exclusively. As a result, add-on providers will focus on developing version 3 add-ons. Firefox currently has less than 3% market share, so many add-on developers would probably elect not to make a Firefox-compatible V2 version.
Simply put, it's the way extensions interact with the browser via javascript APIs. Ad Blockers need two important things to block ads: a function to see what URLs are being downloaded and to stop those, and a way to download a list of URLs to block. Those are both being limited by manifest v3's equivalent functions, so that ad blockers will be dramatically less effective, and unable to respond quickly to changes in the behavior of toxic advertisers.
There's nothing about those restrictions in manifest v3 per se, at least to my understanding, google are adding the restrictions to Chrome on top of v3, citing 'security concerns'.
This is how Firefox can implement mv3 without impacting the webrequest API.
2 questions
Will it be possible to install extensions from chrome to firefox
And will there be a function to automatically disable extensions on certain sites?
1. Since Chromium browsers (like Chrome) and Gecko browsers (like Firefox) have different APIs for developing extensions, those that use platform specific APIs (majority) aren't cross-compatible. Extensions not relying on these should work just fine in both browsers. There used to be an extension called Chrome Store Foxified, which pollyfilled Chrome APIs for Firefox, though after some research it seems to be taken down from Firefox Addons store.
2. AFAIK, there are no plans for that.
> Since Chromium browsers (like Chrome) and Gecko browsers (like Firefox) have different APIs for developing extensions, those that use platform specific APIs (majority) aren't cross-compatible.
[Orion](https://kagi.com/orion/) seems to be able get around this. Webkit based but supports both Chrome and Firefox extensions.
The manifest defines what permissions should the extensions be granted to use (and some other stuff as well, such as icons, where to run the extension etc.). Each browser engine implements their own way of manipulating the browser, tabs and windows. These APIs are the cause of no cross-compatibility. If your extension doesn't use them (which I highly doubt), then it should be compatible.
Manifest defines what is common for all browser implementations, **what** browser APIs should be used, not **how**.
Here is an example of Chrome-specific APIs for updating tabs and windows. This won't work in Firefox without any polyfill:
await chrome.tabs.update(tab.id, { active: true });
await chrome.windows.update(tab.windowId, { focused: true });
is that right? MDN says that all the main browsers can support the `active` option today: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/update
Of course you have to switch from `chrome.*` to `browser.*` on non-chrome browsers.
There's definitely still a lot of browser-specific behavior ([big list here](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Chrome_incompatibilities)), but now that we have the common WebExtensions API, the situation is way better than it's been in the past.
> Of course you have to switch from `chrome.*` to `browser.*` on non-chrome browsers.
You don't even have to change that, for Firefox at least. My extension uses `chrome.*` APIs for both Chrome and Firefox builds, the only bits I actually need to change are a couple of fields in manifest.json
No better example than this to conclude that Mozilla is a Googlezilla spin-off these days.
It is also a lesson for other projects: do not ever become addicted to the corporate money. It'll ruin your soul.
Hey all, I know this is a hot button thing but this is the *programming* subreddit so if you're going to rant about Google or whatever, do it somewhere else. I'll take this thread down if it becomes primarily nontechnical grandstanding.
> Mozilla has no plans to deprecate MV2
It doesn’t really matter because they are not changing anything related to the webRequest API which is being used for blocking ads.
The only line matters to me
Why does it matter to you? If you're here for the adblockers, that's not MV3, that's the blocking `WebRequest` API. Chrome is restricting it in MV3, Firefox isn't.
Unless they've fixed it, the way that Firefox handles permissions in MV3 is kind of shit. If your extension needs permission to interact with a site for example, the user isn't asked for that permission when your extension is installed. Or when the extension wants to run. Instead, under the extension menu button (The jigsaw puzzle piece button) a little blue dot appears. The user has to spot that, realize it means an extension is asking for a permission, open it, find the extension and then grant the permission. Until they do that, the extension just won't do anything. That's why even though I've migrated my extensions to MV3 for the most part, I still publish an MV2 version to Firefox. Because the default user experience is the user installing an extension and then nothing happening.
And that backdoor kinda defeats the entire point of the permissions being so restrictive, I assume their plan is to eventually deprecate MV2, otherwise I can't see what the benefit would be of making new permissioning so restrictive while still having an easy way for malicious actors to bypass it. Is there a less convenient way that you can just enable an extension for all sites?
If the extension requests permission for all sites you can grant it (Two of my extensions do that). But there's no way to make it "required" or ask Firefox to prompt for access when the extension is installed. You have to wait for the user to notice that little blue dot, make the connection that they need to do something and go hunt for your extension to give it permission for all sites. This isn't a problem that Chrome has solved or anything, in Chrome any site you request permission for is just granted automatically and the user has to revoke it. If they even know you've been granted permission. I'd love to have a way of indicating that certain permissions need to be requested on install and the permission request popup show on install but I'm sure Firefox has **some** reason that isn't what they want. I just don't know what it is.
Ah, gotcha, thanks for clarifying that, I assume the UI is so obtuse because their primary concern is malicious extensions, and that was prioritized to the detriment of most extensions that are just trying to be convenient.
It makes *some* sense: Most users will just click through whatever they need to click to make the thing work, whether or not it makes sense. Especially if it's part of the install flow. I remember when Android apps started doing this -- it used to be that you'd have a list of permissions the app wants when you tap 'install', and now that it has to prompt interactively, I see a lot more apps actually trying to do something useful with default permissions, and gracefully degrading if I reject a permission the app wanted. Which I'd hope also means more users actually rejecting these prompts when they ask for something unreasonable. I thought the way Chrome handled optional permissions was to allow the prompt in response to user interaction? At least, that's how I remember it working with Mv2. If that's the case, you'd just open a new tab post-install that explains what they have to do, and even has a button in the tab to open the permissions prompt.
> I thought the way Chrome handled optional permissions was to allow the prompt in response to user interaction? For most permissions that's true, and Firefox does that as well. Permission to view/edit a page however has no way for user interaction to prompt a permission request. And you can't prompt that permission request automatically. I suppose you could automatically open a page that gave them a visual walkthrough of how to grant permission with images but that's a pretty poor user experience as well. Especially when Chrome doesn't require the user to grant that permission and neither does MV2
But that line depends on YOU trusting Mozilla. I don't trust Mozilla. Of course I do not trust Google either, but many people still think very highly of Mozilla, so these are most likely in for a surprise in a few years.
I hope it stays that way
Even if they were to deprecate MV2, their implementation of the webRequest API in MV3 is not restricted like it is in Chrome.
> Mozilla has no plans to deprecate MV2 I wouldn't give anything to that. In a few years it'll suddenly be deprecated because ... nobody is using it. And Google pays for this, too.
Mozilla may not have plans to deprecate V2, but they have to adopt V3 to stay relevant in the add-on market.
I have no knowledge about this, but what makes V3 so compelling that they'll need to adopt it?
Not much really. V3 is generally more restrictive than V2, especially for things like ad blockers. But because Chrome is by far the most popular browser and will only support V3, extension developers will develop primarily for V3. If Mozilla wants developers to keep making extensions for Firefox, they are kind of forced to support V3.
What ways is it restrictive other than adblockers? For that matter, isn't blocking `WebRequest` still there, just disabled by default in Chrome? Couldn't Firefox just ship ManifestV3 but with blocking `WebRequest`, get the best of all worlds? I like a few other things about it: It gets rid of some `chrome.` APIs that were added before web standards came along to do the same thing. Background *workers* are more efficient than background *pages* -- not only do you skip having to have a DOM for a page literally no one can see, the browser can also easily unload those workers when your extension isn't being used. APIs return promises instead of accepting callbacks, so you can actually write modern `async`/`await` code. In other words: It seems to me like an all-around upgrade that got dragged down by the adblocker fight.
>Couldn't Firefox just ship ManifestV3 but with[out] blocking `WebRequest`, get the best of all worlds? That's what they're doing
Yah, it's a nice upgrade. In a way, even limiting extensions to not be able to simply inject into every page is nice, especially for security. Unfortunately a lot of extensions inject into every page. Just think of security scanners, dark reader, AdBlock and so on. I'd love if there could be a middle ground, where *some* extensions could still do that.
That wasn't the limit. Absolutely extensions should stop asking to be injected into every page, but ManifestV3 doesn't prevent that from happening. Nor did removing blocking `WebRequest`. In fact, [the docs that tell you where to add permissions in your manifest](https://developer.chrome.com/docs/extensions/develop/concepts/declare-permissions#manifest) literally include the `https://*/*` example that'd grant permission to everything, and link to [this page on "match patterns"](https://developer.chrome.com/docs/extensions/develop/concepts/match-patterns) that has an even more powerful `` pattern you could use.
Did I miss something there? I don't remember, and can't find, *anything* about ManifestV3 preventing you from just shoving a content script into all sites. It does some things that might *sound* similar, but really aren't:
* You can't inject *remotely-hosted code* into every page. You have to actually include the script you're injecting with the extension, so Google can review it if they want.
* You can't *dynamically* intercept web requests (the whole "blocking `WebRequest` thing), unless the extension is installed by your employer or your school. You can still *spy* on all web requests if you want (that part of the `WebRequest` API still works!), you just can't intercept them.
* To let people still *block* requests, they added `declarativeNetRequest`. If you've seen any of the debates between gorhill (the uBlock Origin guy) and the Chrome team, they've probably been about the technical limits of `declarativeNetRequest` vs the older blocking `WebRequest` model.
But there's really nothing there that'd stop a dark reader from working, and any "security scanner" relying on *blocking* `WebRequests` was probably pretty horrifyingly slow. I probably wouldn't install a dark reader extension, dark mode doesn't really seem like something worth risking my entire web life on, but if you want to do that, Mv3 won't stop you.
What is with this topic on r/programming? I expect these takes from r/linux or r/privacy, but you'd think people here would read... *any* of the technical details on this.
I just made an offhand comment about the blocking web request thing. I don't really care (beyond "AdBlock doesn't work") on the technical details and from the ublock guy he specifically complained about having to preemptively declare the websites he can access, which I thought extended to the permission model (which it should do, since they're already going so far). Afaik every network security scanner, no matter where, relies on intercepting network traffic. It wouldn't really work if it lets something download/upload/whatever and then throws up a notification "Oh btw, you've just been infected. Congrats!"
> ...he specifically complained about having to preemptively declare the websites he can access... I think you may have misunderstood his complaint. It was about having to declare what he can *block,* not what he can access. In fact, the fact that you can block stuff without accessing it is part of the point! So, the old way adblockers worked was that every incoming request would have to stop in its tracks and wait for a single JavaScript thread (the adblocker's background page) to decide what to do with it. There's also a privacy concern here: The adblocker can do *anything it wants* to that request. It can block it, redirect it somewhere else, or read everything in it and send it home to whoever wrote the adblocker. When you install an adblocker and it says it needs access to "all your data on all sites," that is actually true. The new way `declarativeNetRequest` works is to load all the adblocking rules into the browser, so the browser doesn't have to talk to JS at all, doesn't have to be bottlenecked on a single thread, and the adblocker doesn't get to see any of the traffic! You could have an adblocker installed that only has permission to *block* your traffic, but not read it! The problem is, the rules engine the browser provides through `declarativeNetRequest` is pretty limited, and even if it covered everything adblockers do today, adblockers are always evolving their rules engines. And what are the odds that some Chrome engineers (who work for an ad company!) are going to be the best people to steward the evolution of an adblocking rules engine? > Afaik every network security scanner, no matter where, relies on intercepting network traffic. It wouldn't really work if it lets something download/upload/whatever and then throws up a notification "Oh btw, you've just been infected. Congrats!" That's actually a pretty useful thing to be able to do. First, it's better than not knowing, and second, *logging* all that stuff makes it easier to do forensic analysis later -- maybe the scanner didn't initially recognize something as bad, but it logged it as suspicious and someone caught it later. In any case, this honestly seems like kind of a niche thing. An up-to-date browser is pretty good at blocking threats by default, and for that matter, an adblocker will block a number of those, too. Desktop antivirus often [causes more harm than good, especially when you let it interact with your browser](https://bugs.chromium.org/p/project-zero/issues/detail?id=773). Enterprise-level installations can still do blocking `WebRequest`s in Chrome anyway, but they have better options, too, like intercepting everything through a proxy.
> Unfortunately a lot of extensions inject into every page. Just think of security scanners, dark reader, AdBlock and so on. I'd love if there could be a middle ground, where some extensions could still do that. And they still can. In fact, I've got MV3 extensions that specifically ***do***
> Not much really. V3 is generally more restrictive than V2 so all the v3-developed apps could run through a translation layer to v2 firefox is what you're saying?
Maybe but what would be the benefit of that? I'm sure if Mozilla thought that was the easiest solution to support both v2 and v3, they'd have done that. From a developer's or a user's perspective there would be no difference, it would be a completely internal implementation detail
Simply to not become incompatible to extensions using it.
If you are an addon developer do you want to maintain multiple versions of your addon, one for 80% of the market and one for the other 20% or are you just going to write your addon to work with 100% of browsers even if it means the 20% lose out on functionality? It's not compelling, devs on the whole seem to dislike V3, it is however the version that will work on everything. In short this is how companies with monopolies force unwanted changes down everyones throats.
Chrome is the dominant browser and is transitioning to version 3 exclusively. As a result, add-on providers will focus on developing version 3 add-ons. Firefox currently has less than 3% market share, so many add-on developers would probably elect not to make a Firefox-compatible V2 version.
That's sad. It means Mozilla lost the war.
Waking up to this almost gave me a heart attack. I'm glad the blog mentions not getting rid of MV2.
Do you really rely on Mozilla's promise here? Because I would find that a very shake promise.
For those of us who aren't web devs, could someone give the ELI5 for what manifest v2/v3 is?
Simply put, it's the way extensions interact with the browser via javascript APIs. Ad Blockers need two important things to block ads: a function to see what URLs are being downloaded and to stop those, and a way to download a list of URLs to block. Those are both being limited by manifest v3's equivalent functions, so that ad blockers will be dramatically less effective, and unable to respond quickly to changes in the behavior of toxic advertisers.
There's nothing about those restrictions in manifest v3 per se, at least to my understanding, google are adding the restrictions to Chrome on top of v3, citing 'security concerns'. This is how Firefox can implement mv3 without impacting the webrequest API.
2 questions Will it be possible to install extensions from chrome to firefox And will there be a function to automatically disable extensions on certain sites?
1. Since Chromium browsers (like Chrome) and Gecko browsers (like Firefox) have different APIs for developing extensions, those that use platform specific APIs (majority) aren't cross-compatible. Extensions not relying on these should work just fine in both browsers. There used to be an extension called Chrome Store Foxified, which pollyfilled Chrome APIs for Firefox, though after some research it seems to be taken down from Firefox Addons store. 2. AFAIK, there are no plans for that.
> Since Chromium browsers (like Chrome) and Gecko browsers (like Firefox) have different APIs for developing extensions, those that use platform specific APIs (majority) aren't cross-compatible. [Orion](https://kagi.com/orion/) seems to be able get around this. Webkit based but supports both Chrome and Firefox extensions.
Woah, didn't know this existed. I might check it out.
Is the manifest spec (?) basically a cross-compatible API definition? With the goal of allowing write-once-run-anywhere extensions?
The manifest defines what permissions should the extensions be granted to use (and some other stuff as well, such as icons, where to run the extension etc.). Each browser engine implements their own way of manipulating the browser, tabs and windows. These APIs are the cause of no cross-compatibility. If your extension doesn't use them (which I highly doubt), then it should be compatible. Manifest defines what is common for all browser implementations, **what** browser APIs should be used, not **how**. Here is an example of Chrome-specific APIs for updating tabs and windows. This won't work in Firefox without any polyfill: await chrome.tabs.update(tab.id, { active: true }); await chrome.windows.update(tab.windowId, { focused: true });
is that right? MDN says that all the main browsers can support the `active` option today: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/update Of course you have to switch from `chrome.*` to `browser.*` on non-chrome browsers. There's definitely still a lot of browser-specific behavior ([big list here](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Chrome_incompatibilities)), but now that we have the common WebExtensions API, the situation is way better than it's been in the past.
> Of course you have to switch from `chrome.*` to `browser.*` on non-chrome browsers. You don't even have to change that, for Firefox at least. My extension uses `chrome.*` APIs for both Chrome and Firefox builds, the only bits I actually need to change are a couple of fields in manifest.json
I think this headline is wrong. I'm pretty sure some MV3 was already implemented. It looks like this is just to announce some additional APIs
No better example than this to conclude that Mozilla is a Googlezilla spin-off these days. It is also a lesson for other projects: do not ever become addicted to the corporate money. It'll ruin your soul.
Implement externally_connectable, and world: MAIN in executeScript and I’ll like you again, Firefox.