Xcode 13 was required

@nbe I never got notified you replied. I am able to set, get and remove session and local storage from my background page/script without issue. I am not using the safari converter however, so perhaps it's an issue with that or how you are going about setting/getting. That being said the person who replied has good advice, I'd do what he says.

Where are you trying to store session data? You mentioned your background script, but it is unclear if you are trying to set session data for the background page, popup, extension page or on a webpage via content script.

I think how you will open the containing app depends on your implementation and from where and how you are trying to do so. Using a custom URL scheme is the way I do it. I can open my containing app from a popup, content script, bundled html page or background by calling the window.open method like so: window.open("customURLscheme");

This seems to be happening to my extension as well, and possible a new related issue? [EXExtensionContextImplementation _derivedExtensionAuxiliaryHostProtocolWithContextClass:]

I am still hoping for clarification here. To be clear, I am curious if it is possible to accomplish similar results as browser.contextMenus.create({...}), when not using web extensions, but rather the Safari App Extension swift api? Further, if the api doesn't exist for those methods, is it somehow possible to use the web extension api alongside the swift api?

I am still searching and hoping for an answer to this, bumping to get some visibility.

Sorry for the late replies. This is not about web extensions. I believe I figured out why this was happening. Since I have the current (non-development) build of my extension on my development machine, I always disable the extension before testing. When I test new builds, I test in Safari and a fresh instance of Safari is initialized, which has my non-development extension disabled. That means every time I re-build, I have to re-enable the extension. If I do not disable the extension before building development versions, I seem not to encounter this. It all sounds rather long winded and confusing, but since realizing this, I haven't encountered the issue, so far.

The icon appearing in the accent color denotes that the extension has access to the current tab. Thank you for the reply. It seems well intentioned but an unfortunate ui decision. I suppose the color scheme is automatically adopted by all extensions without developer ability to change it to something a bit more pleasing to the eye (like the new privacy extension has)? The new privacy extension seemingly has 2 states - active = normal monochrome/grayscale color and inactive - opacity set to x amount It's seems odd that 3rd party extensions don't automatically adopt that scheme...

I still can't get panels to open from the extension page / safari app. Can we get some clarification? warning: unable to obtain service marshal for app-modal session It would be great if users could accomplish tasks that require open/save panels from the extension without needing to open the containing apps.

Thanks for the reply, Timothy. That's interesting. I did not try it myself (yet). I figured the documentation would valid, but perhaps it is not and they changed it along the way at some point. Even if it *does* work as they've suggested in their docs, I am assuming Safari will not mimic this behavior; is that fair to say? The reason I am curious about all this is that I am trying to figure out solution to deal with strict CSPs when attempting to inject dynamic javascript creating by an extension. Currently I add a listener that detects security policy violations when attempting to inline code and if that happens, I fall back to "evaling" the code from the content script, but then that "evaled" code lives in the content script context and not the page. I should note that the extension is written in the current App Extension format, not WebExtensions, but I am considering a re-write if feature set is "better" with one format. One method would be to rewrite the headers (if webRequestBlocking was supported) to add an exception for the script(s), but I am not sure if that is a great solution even if webRequestBlocking was supported.

Thanks for the reply, Timothy. The model you are using for WebExtensions sounds like it hasn't deviated from the model you are currently using with Safari App Extension, is that correct? When you say that it matches other browsers are you referring to Firefox or Chrome? It seems like they handle Page CSPs a bit different. I can't link out here in the forum but I will include an excerpt from Chrome's documentation: Additionally, the CSP of the page does not apply to content scripts. More complicated are <script> tags that content scripts create and put into the DOM of the page they are running on. We will refer to these as DOM injected scripts going forward. DOM injected scripts that would be executed immediately upon injection into the page will execute as you might expect. Imagine a content script with the following code as a simple example: document.write("<script>alert(1);</script>"); This content script will cause an alert immediately upon the document.write(). Note that this will execute regardless of the policy a page may specify. Currently in Safari, if a page csp exclude inline scripts, document.write("<script>alert(1);</script>"); will not execute. However with Chrome this is seemingly possible, regardless of the page csp. Will the new WebExtension model be in line with this?

What version of Xcode and Safari are you using? I can confirm that in Xcode 11.0 and Safari 13.0.1 that your content scripts "works" and I am not experiencing the the issue you describe. However, I have not tested in newer versions of Safari or Xcode. What is document.html? Are you trying to target the html element? You should probably use document.documentElement - that line of your code is throwing an error.

Can we get some clarification here?Is there any way to display a NSPanel, NSAlert, NSSavePanel, etc... from within SFSafariExtensionHandler?