Bug 262383 – Safari web extension background script becomes unresponsive in Safari 17, macOS 14.0 Sonoma

• Component: WebKit Extensions
• Status: RESOLVED MOVED

Created attachment 467975 [details]
A background script that has failed to load in Safari 17

I develop a web extension. The extension runs on manifest version 2. The extension has been in the Mac app store for about two years, running without issue. Its last update was roughly four months ago.

Recently, I received a couple user reports that, on Safari 17, in macOS 14.0 (Sonoma), the extension would stop working after some time had passed. Today, I updated my own machine to test, and sure enough, after some time passed, the extension stopped working, and became completely unresponsive. Here are some of the symptoms I've observed:

- It is the background script that becomes unresponsive. The web extension's content scripts continue to work as normal.
- I've tried updating the extension to manifest version 3, but the issue persists.
- The chrome.browserAction.onClicked listener does not fire.
- The chrome.commands.onCommand listener does not fire.
- The chrome.contextMenus.onClicked listener does not fire.
- When the extension is in this unresponsive state, and I inspect the background script, I'm unable to use the console—it too is frozen and unresponsive. I cannot even execute expressions. Activity Monitor shows no unusual activity, and there is nothing in the background script code that would cause the script to hang like this.
- The browser page itself continues to work.
- There are no errors reported.
- Using manifest version 3, I can sometimes see the message "[EXTENSION_NAME] (failed to load)" When I go to the Develop > Web Extension Background Content menu item.

If I quit and reopen Safari, the extension will work again, but then stop working again after some time has passed.

Interestingly, if the extension has become unresponsive, and I open a new tab, all of the previous events that I tried and failed to fire will execute in sudden succession, as if they had all been stuck in a kind of queue and were suddenly released at once. This implies that the background script is still running, but that it is "lost" somehow.

I've tried a few workarounds, like calling setInterval, or executing recursive promises on timer, just to see if I could somehow keep the background script "alive". But these have not had any effect.

[Radar WebKit Bug Importer]

<rdar://problem/116245733>

[Karl Dubost]

@punk.salt2200,
thanks for the report and all elements giving context.

Without the code of the extension or a reduced test case reproducing the issue that will probably be impossible to diagnose and fix.

(In reply to Karl Dubost from comment #2)
> @punk.salt2200,
> thanks for the report and all elements giving context.
> 
> Without the code of the extension or a reduced test case reproducing the
> issue that will probably be impossible to diagnose and fix.

Thanks—yeah, that's fair. I'll see if I can create a reduced test case.

I did discover a couple additional things as I debugged further.

The first is that the amount of time the background script stays "alive" for is quite consistent—just under 8 minutes. After that, it dies/goes away.

I also discovered that by calling `runtime.sendMessage` on an interval from the content script, and sending an arbitrary response back from the background script, I can keep the background script alive. I recognize that's more of a workaround than an actual fix, but it does seem to work.

One final point of note: this issue seems similar to a pair of issues that have plagued Chrome for some time now:

- https://bugs.chromium.org/p/chromium/issues/detail?id=1271154
- https://bugs.chromium.org/p/chromium/issues/detail?id=1316588

[Timothy Hatcher]

Thanks, that is helpful!

[Timothy Hatcher]

This has been resolved in Safari. The WebKit fix also landed in bug 263287.