[dessant]

I have taken the time to comment on the pull request before it was merged. I have mentioned several use cases, and offered an explanation for why the feature is important. If that is not enough for you and for Mozilla engineers, then perhaps the correct response is to simply abandon their platform. I've done my part, and I'm not going to further sacrifice my free time because some people have no concern about how their actions affect other people's lives.

It's certain that 2 years from now extension developers will still be getting support requests and receive negative reviews because of that commit, even if an alternative API is released in the next few months. But who cares, it's not you who has to find a solution and deal with users.

All of this could have been averted by simply offering an alternative API in the same browser version in which the new restriction was implemented. There was no pressing need to immediately restrict the API.

> Disallowing the modification of Access-Control-Allow-* response headers will impact extensions that need to download page content.

> Search by Image sets CORS headers for some images in order to download them from the content script before uploading to a search engine. In many cases an asset will only be served if the request contains the correct origin, referrer and cookies. Reproducing such a fetch request was impossible from a background page last time I tested, and even if configuring all aspects of a request becomes possible, it could still open up extensions to security issues, because it's difficult to figure out if certain data types would be sent by the browser if the request would be made from the page context, such as the referrer. We would also need to request additional permissions, such as access to HTTP cookies.

> Extensions used for archiving pages would no longer be able to create faithful representations of the tab content. Advanced ad blockers such as uBlock Origin would be impacted as well. There is a general issue of extensions not being able to access certain parts of the page, such as a tainted canvas in Chrome, or a closed shadow DOM in Safari, and this restriction would make the problem worse.

[jcranmer]

I will admit, I did miss your first message. But it was already responded to, with links to the bugs tracking the things that would have provided the functionality you requested.

> All of this could have been averted by simply offering an alternative API in the same browser version in which the new restriction was implemented.

You mean like manifests v2, which wasn't affected?

I will also note, it was this comment in particular that set me off:

> It must be possible to prevent a patch from being released in the stable version of Firefox. You must be aware that this change will make it difficult to port extensions that need to access arbitrary page content. Extension developers have enough work on their hands already, and we shouldn't need to spend more time submitting feature requests and then defending use cases that are already obvious to your team.

This kind of "I demand you do what I want, and I'm going to refuse any attempt to answer why you should" comment is one that I believe it reasonable for a developer to ignore.

[dessant]

It will affect cross-platform extensions that need to migrate to Manifest V3 this year. Some projects will be forced to stay on Manifest V2 just for Firefox, substantially increasing development cost because of the need to maintain both MV2 and MV3 versions across platforms, or abandon a substantial part of Firefox users and only support the most recent browser version, assuming that a fix is even implemented in the browser.

Regarding your edit, I have not demanded anything, but asked if it would be possible to delay the release, for all the discussed reasons. For which I have received a non-answer, "it has already been merged" is not a valid reason for not correcting a mistake, and asking people to invest even more of their time in this and repeat what has already been discussed in a new bug report was just the last drop that made the lack of respect for other people's time obvious.

[paulryanrogers]

Is it Mozilla's fault Google marches on with MV3 with no regard to standards?

Mozilla will continue to support V2 and working towards V3 support. Expecting a fully compatible implementation on the first go is a lot. Especially since Mozilla has a fraction of the budget and other priorities besides aping Chrome.

[dessant]

The issue is not compatibility with Chrome. Projects that were otherwise ready for the Manifest V3 migration and have worked towards that goal in the last few months can no longer proceed with the migration, their work has been made obsolete. The code we wrote no longer works, and we don't even know how or if the issue will be addressed before the next major Firefox ESR release. If a solution is not released in the next few months, this issue will prevent some projects from migrating until the end of 2024, or they will have to contend with dropping support for Firefox ESR.

I hope reading the linked pull request thread and the comments here will make it easier to see what went wrong, and why listening to the people that work with these extension APIs is important.