@tuggif No need to remove the content script from the manifest. Here's an update to the snippets I posted that would fix the problem: content.js: const port = chrome.runtime.connect({ name: 'TEST' }) // SEND MESSAGE IMMEDIATELY port.postMessage({type: 'ANYTHING'}) port.onMessage.addListener((message) => { console.log('RECEIVED TEST MESSAGE', message) }) background.js: let canSendMessage = false; chrome.runtime.onConnect.addListener((port) => { if (port.name !== 'TEST') return console.log('test port connected', port) port.onMessage.addListener((message) => { // PORT RECEIVED A MESSAGE, NOW WE CAN RESPOND canSendMessage = true console.log('SENDING PORT MESSAGE') port.postMessage('HELLO') }) })

Thank you for addressing this, the workaround appears to fix the problem on Safari 18 / Sequoia RC. Will this be included in the public Sequoia release next Monday, 9/16?

Update: I filed an issue with Feedback Assistant back when I initially discovered this issue. They reached out and this appears to be fixed on the latest developer beta for Sequoia macOS 15.

I've reported this issue in this thread as well https://developer.apple.com/forums/thread/671649. bweinstein claims this was fixed, but it still hasn't been. Hoping he or @timothy.hatcher can clarify or provide an update.

I've just noticed the same behavior. In fact-- instead of getting the disconnect, I'm getting an additional connection request from browser action (even though it's not open). Almost like some phantom instance has been opened.

Hi there, one year later and we're experiencing this problem on my team as well. Any luck lu.xu? Or can anyone from Apple comment on this? Sounds like a bug. Thanks, Tyler

Thank you, bweinstein. I've filed under FB8967592 with a sample demo. Hope that helps.