When you have a blank Safari new tab open, the browser.tabs.query API inaccurately includes those tabs in results that include a url or title in the query options. To reproduce, open several tabs, and a blank new tab. Open the background page devtools, and execute the following command: browser.tabs.query({url: 'https://github.com/'}, console.log) In addition to any potentially valid results (if you have github.com open, for example), there will also be an entry for the blank tab, which has an empty, non-matching URL. Tab { active: true, audible: false, height: 1095, highlighted: true, id: 6, incognito: false, index: 3, isArticle: false, isInReaderMode: false, mutedInfo: {muted: false}, pendingUrl: "", pinned: false, status: "complete", title: "", url: "", width: 1792, windowId: 1 } I hope that this bug can be addressed, as it causes some unexpected behavior.

Background pages for Safari Web Extensions appears to be unable to load a local bundle resource to create a Web Worker script, even when the script is included in the web_accessible_resources in the manifest, as well as the worker-src in the content_security_policy. I have no problem doing so on the other web extension platforms (Chrome, Firefox) with the same extension and code. I've already filed a bug for this FB11955055, wondering if anyone else has been faced with this problem. It seems similar in nature to this issue https://stackoverflow.com/questions/73399285/safari-extension-background-page-unable-to-fetch-web-accessible-resource, but that one Apple claims to have resolved in Safari 16. Edit: added error message

I'm trying to find a way to block any requests to domains my app decides not to trust. I've discovered the default capabilities of App Transport Security - https://developer.apple.com/documentation/bundleresources/information_property_list/nsapptransportsecurity, which is a great start, but would still allow a remote connection to a third party that uses HTTPS. I ask this in the context of a Safari App Extension, although I'm sure this could apply to any macOS/iOS application. Web extensions (Chrome/Firefox/Edge) already provide this capability, and I'd like to secure my application accordingly.

I'm trying to convert a Safari App Extension to the newer Safari Web Extension API, and having an issue with an injected iFrame we use to protect user data. Inside our provided iFrame which which we source from: safari-web-extension://<ID_HERE>/<HTML_FILE_HERE> and is externally_connectable via the manifest.json. Any scripts that run inside the iFrame are able to initiate communication with background scripts with no problem. However, any message initiated from background never registers on any onMessage listener. For example: // iframe.js // WORKS FINE browser.runtime.sendMessage({ greeting: "hello" }) .then((response) => { &#9;&#9;console.log("Received response: ", response); }); // NEVER FIRES browser.runtime.onMessage.addListener((request, sender, sendResponse) => { &#9;&#9;console.log("Received request: ", request); }); I'm convinced this is an Apple bug because this same scenario for the App Extensions receives the request from the background scripts no problem. Can anyone prove me otherwise?

I'm very excited about bring web extensions back to Safari. I have an existing Safari App Extension and would like to port it back to Safari Web Extensions. I have a question about backwards compatibility. Will Safari 14 be backwards compatible with older OS such as High Sierra or Mojave?