Hey there, let's break down the issues you're facing with your MV3 extension on macOS—this is a common pain point when migrating from MV2, since service workers behave drastically differently from background pages. Let's tackle each part step by step:

First, let's decode your error logs #

• "Could not establish connection. Receiving end does not exist.": This almost always points to broken message communication between your service worker and content script/popup. The most likely culprit is your service worker getting garbage-collected by Chrome, then failing to re-establish listeners or connections when restarted.
• "ResizeObserver loop limit exceeded": While this is usually a non-blocking warning, unhandled loop errors can clog the main thread, indirectly causing your extension to freeze.
• "Request failed with status code 403": MV3 tightened permission rules—your old MV2 setup might have relied on implicit permissions that aren't explicitly declared in MV3.

Core Issue: Service Worker Lifecycle Quirks (MV3's Biggest Gotcha) #

Chrome aggressively recycles idle service workers, and this behavior seems more pronounced on macOS. Your current code has a few red flags that could be triggering the unresponsiveness:

1. Improper Async Handling in chrome.runtime.onMessage #

Your listener uses Promises but doesn't tell Chrome to keep the message channel open for async operations. When Chrome sees no return value, it closes the channel immediately, leading to failed responses and potentially unstable service worker state.

Fix your listener code like this:

chrome.runtime.onMessage.addListener((message, sender, sendResponse) => {
  let needsAsync = false;

  if (message === 'toggle-popup') {
    needsAsync = true;
    updateApplicationTab((idTab) => {
      chrome.tabs.sendMessage(idTab, { message: 'clicked_browser_action' });
      sendResponse(); // Call this AFTER your async logic completes
    });
  }

  if (message === 'toggle-popup_set_id') {
    needsAsync = true;
    chrome.tabs.query({ active: true, currentWindow: true }, tabs => {
      chrome.runtime.sendMessage({ type: 'setActiveTab', data: tabs[0].id });
      sendResponse();
    });
  }

  return needsAsync; // Return true to keep the channel open for async work
});

2. Lost State/Listeners After Service Worker Restart #

Unlike MV2's persistent background page, MV3 service workers start fresh every time they're recycled. Any global state or listeners you set up inside callbacks will be lost.

Fixes:

• Store persistent state in chrome.storage.local instead of memory variables.
• Register all critical listeners (like onMessage, onTabUpdated) in the top-level code of your service worker, not inside other callbacks. This ensures they're re-registered every time the service worker starts up.

3. Content Script Injection Gaps #

Static content scripts (declared in manifest.json) only inject when a page first loads. If your service worker restarts later, existing tabs won't re-inject the script, leading to broken communication.

Adjust your manifest to cover both static and dynamic cases:

{
  "background": { "service_worker": "js/background.js", "type": "module" },
  "content_scripts": [{ "matches": ["<all_urls>"], "js": [ "js/contentscript.js" ] }],
  "host_permissions": ["<all_urls>"], // Required for MV3 to access all URLs
  "permissions": ["tabs", "storage", "scripting"] // Add permissions you actually use
}

If you need to inject scripts into existing tabs after the service worker restarts, use chrome.scripting.executeScript instead of relying solely on static injection.

When There Are No Error Logs #

This usually means your service worker was completely recycled and didn't trigger a restart. Try these fixes:

• Add chrome.runtime.onStartup and chrome.runtime.onInstalled listeners to your service worker to initialize critical logic when the browser or extension starts.
• Avoid long-running synchronous code in the service worker—Chrome will kill it faster if it blocks the event loop.
• Check the state of your service worker in Chrome's chrome://serviceworker-internals/ page to see if it's being recycled frequently.

Fixing the ResizeObserver Warning #

While this isn't the root cause of your unresponsiveness, it's easy to fix:

const resizeObserver = new ResizeObserver(entries => {
  try {
    // Your resize handling logic here
  } catch (err) {
    if (!err.message.includes('ResizeObserver loop limit exceeded')) {
      throw err; // Only ignore the specific loop error
    }
  }
});

内容的提问来源于stack exchange，提问作者Mykyta