Content script port disconnected during instant navigation

201 views
Skip to first unread message

Ioannis Charalampidis

unread,
Jan 30, 2023, 10:28:26 AM1/30/23
to Chromium Extensions
Hi all,

I am writing an MV3 extension and I am experiencing a weird behavior with instant navigation pre-rendering on Chrome 109.0.5414.119 (Official Build) (x86_64). From my PoV it looks like a chrome bug, but I wanted to run it through you first.
  1. The extension injects a content script on every page
  2. The content script almost immediately does `runtime.connect`
  3. The background page uses the connection event to establish an RPC to the page
This behavior seems to work perfectly fine in all normal navigations.

It also works perfectly when the frame is rendered in the background due to an instant navigation pre-render effect. (meaning that I get an `onConnect` event in the background page when the frame is loaded).

However, when the background frame becomes active:
  1. The port gets disconnected from the background page's side
  2. But no disconnect event is emitted to the content script!
I am not sure what's the expected behavior here. Should the content-scripts be executed? And if yes, is the port expected to be disconnected? I am assuming the one-side disconnect thing is an actual bug...

In the meantime, do you know how can I reliably identify from the content script's PoV if the page is being pre-rendered and when it transitions to active? It could help me at least prohibit the content-script to connect...


Ioannis Charalampidis

unread,
Jan 30, 2023, 10:58:32 AM1/30/23
to Chromium Extensions, Ioannis Charalampidis
Btw, to whoever is following this, I just found out this:

which means that you can use this for bootstrapping the content-script logic only when not pre-rendering:

// If the document is pre-rendering do NOT bootstrap right away
if (document.prerendering) {
  document.addEventListener("prerenderingchange", (ev) => {
    if (!document.prerendering) {
      bootstrap();
    }
  });
} else {
  bootstrap();
}

I can use this to mitigate my issue, but the overall question regarding the port behaviour still remains...
Reply all
Reply to author
Forward
0 new messages