Reviving this thread because I am still seeing this issue with Web Extensions. It would appear that until you "Always allow on every website" the extension simply doesn't run (even in the background) in order to receive the onInstalled event. Furthermore, even after setting the proper web site permissions and toggling the extension off and then on, it does not 100% of the time fire the onInstalled event.
In my case, we want to show a tab with a welcome page for quickly onboarding after installing the extension. Specifically, we want to describe Safari's opt-in site permissions and how to make our extension work with those settings, but we are in a catch 22 because we can't even show that page until the user opts in to site permissions.
lollimatt
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Post
Replies
Boosts
Views
Activity
I would like to understand the reasoning here as well. It seems like a Safari App Extension gets default access to whatever pages the user visits, whereas a Safari Web Extension has to ask for specific web page permissions. I can understand the latter from a privacy/security perspective, but it doesn't make much sense for the former because an App Extension has free rein. Why is an App Extension treated differently from a Web Extension in this case?
For example, 1password's App Extension has access to all sites without an explicit opt-in:
...but Okta's Web Extension does not:
Both have very similar functionality, that of suggesting form-fills for logins on any web site, but because Okta is a Web Extension, it gets treated differently. Why is that? It seems like both App Extensions and Web Extensions should require the same opt-ins or not. Otherwise, it's on the developer to opt for a native App Extension over a Web Extension for the better UX.
I found a workaround. When you want to close your popup from within the popup, do this:
browser.runtime.reload();
Weird, right? It closes as a side effect of reloading the popover. Super hacky but keeps me moving while Apple fixes the underlying issue or otherwise gives us a way to close it.
@bweinsten Could you provide the code to your test extension? I will make a barebones extension to test myself, but it could expedite things if I could see yours working. To be clear though, this is the popover that appears when the user clicks the icon in the toolbar, not a window that is opened using window.open().
@vkyrychenko87 No luck. Seems Safari is the only browser conforming to the MDN docs, OR the other browsers use a script behind the scenes to open the window and Safari does not. Either way, Safari is the outlier. In addition to my X button, though, I also have the need the programatically close the popover when the user clicks a link in it to navigate on the current tab. In instances where a new tab is opened, the popover goes away automatically, but if a link opens in the current tab, the popover just hangs around, obscuring the view. So my close method has two use cases: 1) Manually click the X button to close, and 2) Automatically close when a link is clicked in the popover.
There has to be a way to do this, even if it's delegating to the native swift handler. Real head scratcher that it's non-obvious.
I think I found a workaround myself...still testing though. It appears if you get the currently active tab when then tab id is 0, you can get the REAL tab id. Example:
private getRealTabId(tabId: number): Promise<number> {
	return browser.tabs.get(tabId) // tabId=0 here
		.then((tab: Tab) => {
			if (!tab) {
				console.debug(`Could not find tabId=${tabId}. Looking for active tab.`);
				return browser.tabs.query({active: true, currentWindow: true})
					.then((tabs: Tab[]) => {
						if (tabs.length) {
							const tab = tabs[0];
							console.debug(`Found active tab for tabId=${tabId} with tabId=${tab.id}`);
							return tab.id; // this tab id is non-zero! yay!
						}
						throw new Error("Tab not found");
					})
			}
			return tabId;
		});
}
This would not be a perfect solution, though, since a user could be quickly switching tabs and thus resulting in a new active tab, but it may be "good enough" for now.