Initial content script injection & removal of HTML elements on inactive tabs

[Dustin Byers]

Hi all, apologies in advance to the long post, but for some necessary context - I have a chrome extension built in React/TS, with a sidebar that is mounted to the body of the active page through the manifest, on document_start. I've had some issues in the past with several releases where there was a memory leak of some kind, slowing down some users browser to some degree. This has been a pain to debug, but the working thought until now, has been that there were orphaned scripts and/or DOM event listeners/chrome apis that were still firing on inactive/hidden tabs. To deal with this, I use a few apis such as Page Visibility, to unmount the UI components, and deregister event listeners in hidden/inactive tabs, and the reverse  when visible. This introduces a lot of complexities when trying to persist state across tabs, not to mention a less than perfect UI/UE, as the remounting causes some flickering.

My question is related to the last part of the above - Is this necessary to fully remove the UI on inactive pages? I've read through the Page Lifecycle API and it seems like the browser should handle any garbage collection, suspension, freezing, etc, on it's own. This makes me think that the current approach is likely overkill, and the original problem was really with respect to missed listeners, and/or chrome apis being invoked from inactive tabs.

Also, just want to say this forum has been a great resource! I appreciate all the  conversation, and thanks in advance for the responses!

[Patrick Kettner]

Hey Dustin!

This really doesn't sound like anything specific to extensions. Especially if you are injecting a content script. At that point, its more or less just standard React/TS. If you are having a memory leak, it sounds like a potential bug either in React or your code. Rather than constantly mount and unmount the same components, my first step would be to try to track down what specific code is causing the memory leak. You say it was "slowing down some users to some degree". Does that mean you aren't able to replicate? If not, then the zeroth step for me would be to instrument an update to the code to try to collect . At the very least, maybe use something like preformance.memory/measureUserAgentSpecificMemory to track memory over time, and if it grows unexpectedly, beacon out. Probably important to note that calling either would force a garbage collection. 

As for maintaining state across pages, if you are mounting and unmounting the page, then could you call something like chrome.storage.session to store the state on teardown, and then get the value on update? Broadcast that a change occurred with a chrome.runtime.sendMessage so any other visible page knows to reload the values.

> Is this necessary to fully remove the UI on inactive pages

Definitely should not be.

> Also, just want to say this forum has been a great resource! I appreciate all the  conversation, and thanks in advance for the responses!

🥰 - happy youre here!

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/c4572713-d6f9-4661-9c46-e80ef17d507an%40chromium.org.

[wOxxOm]

The underlying problem you've mentioned seems to be "orphaned scripts" which appear on extension update or reload, assuming you re-inject them via executeScript. You can fix it by unregistering those DOM events as shown in https://stackoverflow.com/a/57471345.

[wOxxOm]

Just in case, an example of re-injecting on update: https://stackoverflow.com/q/10994324

[Dustin Byers]

Thanks all, I'll have to look into more wrt the perf api monitoring, and thanks @wOxxOm, I had tried to follow this pattern to begin with, but I'll check through this again, as I suspect I've missed some.