- Notifications
You must be signed in to change notification settings - Fork27k
fix(devtools): false positive app not detected#66166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:main
Are you sure you want to change the base?
Conversation
Since Manifest V3, the service worker (background) gets terminated after 30s of inactivity. This can break the initialization phase of DevTools or the BE-FE communication channel, if already initialized. To prevent that, we emit a heartbeat in a >30s interval.
ec1f7a3 tob970fa1Compare
dgp1130 left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Wow, that seems really rough.
I understand the browser wanting to kill unused service workers, but having it just drop messages seems really bad? I would expect subsequent messages to restart the service worker rather than just silently dropping them.
hawkgs commentedDec 19, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
I think we can certainly restart/respawn the service worker but the caveat here is that our extension should know how to handle this case, i.e. we will need some form of a reconnection logic. A heartbeat seems totally fine, in my opinion, since the SW will get deactivated when you are not inspecting an Angular app anyway. When you are inspecting an Angular app, on the other hand, the benefits of letting the SW do its resource-saving things seem really marginal to me, since the extension is meant to be used actively, not passively. The messages are dropped because the message buses are destroyed on disconnect. If we don't do that, I think, any subsequent messages after the disconnect event will restart the SW. But the SW will be pristine, meaning that all event handlers need to be recreated. Basically, here you'll need the reconnection logic, I believe. Edit: Actually, after writing this message, I realized that I got confused – the heartbeat is emitted from the content scripts (mixed it up with BE scripts) which are installed on all apps, not only Angular, which means that the SW will always be active. Let's move this forward and I can further investigate a reconnection approach and whether it's substantially beneficial. In the worst case scenario, the extension will act as if we are using Manifest V2 with this piece of code. |
Uh oh!
There was an error while loading.Please reload this page.
I think we finally got it.
After catching the issue and analyzing the logs from the synced logger, I noticed that the SW gets disconnected automatically roughly 30s after the last emitted message via our message buses. After trying to reproduce this, I noticed that it happens consistently. Turns out that with the introduction of Manifest V3, the service worker does indeed get terminated after 30s of inactivity (Ref:https://developer.chrome.com/docs/extensions/develop/concepts/service-workers/lifecycle#idle-shutdown). So, what I did is to emit a heartbeat every 20s to keep the SW alive.
This is very likely, the core reason for the most of "App not detected" complaints. It also has another implication – even if the app is initialized, leaving your workspace for a couple of minutes, for example, will break the FE-BE communication channel and prevent the normal DevTools operations.
Note: Since I did some tests with the web store DevTools, it appears that the SW termination takes a bit longer. Now, I haven't investigated thoroughly what could be the reason, but I suspect that it could be related to#66011.#66011 is still not on prod, but the non-optimal infinite
detectAngularmight have acted as a heartbeat in some cases, albeit emitted via theSamePageMessageBus, that is, within the content script context. This will require carefully following the flow of messages to verify. Anyway, the heartbeat introduced in this PR, directly pings the SW (chrome.runtime.Port) as it should to prevent the termination.