User Profile

My webRequest.headersReceived handlers for top frame receive a random number at details.frameId instead of 0 as per the spec.

UTF-8 characters in JS code strings such as ✕ or ’ are not handled properly and come out wrong when displayed/printed.

I have a webRequest.headersReceived listener on my extension and while Chrome and Firefox correctly calls the listener for 302 redirects with intermediate URLs, Safari does not.

The spec - https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/onHeadersReceived specifies a type property: type webRequest.ResourceType. The type of resource being requested: for example, "image", "script", "stylesheet".

Setup: A chrome.runtime.onMessage listener attached on the top frame which sends no response, and another listener attached on a frame which sends a response. The background page sends a message to the tab. What happens: The top frame listener is invoked and returns undefined. A response is returned to the background sendMessage call. What should happen: The listener on attached on a frame should be invoked after the top frame listener and checked for either a response or returning true with an intention to respond asynchronously and only then a response should be returned to the background page.

In the current Safari App Extension framework the background Swift process can be removed by the OS at any point while Safari is still running. This creates multiple issues:1. You cannot store any state about the tab in the background, which is neccessary if you want to update the button label and icon, or context menu options based on the state of the tab2. There may be a big delay between user pressing the extension button and any visible response, since the background app extension process needs to be reinitialized if it got killed.My question is whether there is a way to maintain the background app extension process running for as long as Safari itself is open and/or would that be considered bad practice? If it is, what would be the way to mitigate the issues outlined above?

Since there is no way to programatically add context menu items, my idea was instead to add a bunch of placeholder items to Info.plist:<key>SFSafariContextMenu</key> <array> <dict> <key>Text</key> <string>menu0</string> <key>Command</key> <string>menu0</string> </dict> <dict> <key>Text</key> <string>menu1</string> <key>Command</key> <string>menu1</string> </dict> [...] <dict> <key>Text</key> <string>menu9</string> <key>Command</key> <string>menu9</string> </dict> </array>and hide them by default, or change their names and display when contextually required in the background Swift code by usingfunc validateContextMenuItem(withCommand command: String, in page: SFSafariPage, userInfo: [String : Any]? = nil, validationHandler: @escaping (Bool, String?) -> Void)The problem is that the background app process is often killed by the OS and since the bg app startup takes some time, validateContextMenuItem upon background page restart does not respond adequately quickly, in which case the context menu displays all the placeholder items instead.Naturally, this is an unacceptable behaviour, so my question is whether there is a way to reliably programatically control the contents of the context menus in Safari?In the old Safari extension framework we used the popover on the button to display contextual options for users, because the button had two behaviours: one on click, and one on click-and-hold. However in the App Extension system you can only choose one behaviour and we need the single-button click behaviour in our extension to just perform the extension action, so this is not an option for us.