All of my third party extensions have blue icons now, in Safari 14.0. It looks pretty awful. Is there a way to keep the monochrome colors or a way for us, as developers, to provide a different kind of icon to sustain the monochrome colors for our extensions? I am assuming the blue color denotes something, like the extension being "active". I wasn't able to find documentation on this change nor any related api doc.

Clicking an anchor tag <a> using a download attribute and data uri as the href doesn't trigger a download in a webextension bundled html page. Rather it opens a new tab and navigates to the data uri. This is the not the same behaviour users experience on the web nor the same behaviour as a Safari App Extension bundled html page. Is this intentional? Is this a shortcoming of the WebExtension API? Is there any way around this? Any guidance would be appreciated.

Currently Safari does not support modifyHeaders as an action.type when using the declarativeNetRequest API. Does the Safari team plan on building out this action.type for the API? Safari seems to be the only major browser that lacks support for header manipulation, even with the mv2 APIs (ie. webRequestBlocking). Is this purposefully being omitted? If so, why?

Adding the webRequest permission to my manifest file does not give me access to the webRequest WebExtension api in my background page. From looking at the docs, I see that webRequestBlocking is not supported, but no mention of webRequest not being supported. I am on macOS 12.1 and Safari 15.2. Example: ... "permissions": [ "<all_urls>", "webRequest" ] ...

Currently, if a page csp disallows inline scripts, but the content script attempts implant inline scripts (DOM injected scripts) - the code will fail to execute. This is an issue with the current Safari extension model. The effect of this is that content scripts that inject dynamic (user-generated) content can not properly interact with the page context. This is also an issue with other major browsers, however I do not believe Chrome has this restriction. The reason I say "do not believe" is because the documentation indicates that "page csp does not apply to content scripts", but I have not personally tested this. I'd like to know is this restriction will be present with the new Safari WebExtension model, especially considering that webRequestBlocking is not supported (which would be the only workaround I am aware of).