Behaviour of extension message ports and bfcache

[oliverdunk]

Back/forward cache (bfcache) is an optimization in browsers where pages are suspended but cached upon navigation so that they can be more quickly restored if a user decides to return.

If a page that is entering the cache has an open message port to another part of the extension, it is unclear how this should be handled. For example, it could be kept alive with messages buffered, kept alive with messages dropped, or immediately closed. Alternatively, it could be dropped but only if a message is received.

We discussed this at TPAC and our current thinking is to immediately drop ports. This may require more work for some developers than alternatives, but is hopefully consistent behaviour that reduces the risk of extensions behaving in unexpected ways.

Opening this issue to track any further discussion and rollout.

[oliverdunk]

@zombie / @Rob--W: The conclusion we came to at TPAC was based on the understanding that the current Firefox behaviour is to immediately close ports. After some testing, however, it seems like the port actually remains open indefinitely and messages are dropped while the page is suspended. Does this match what you are seeing, and does it change your thoughts here?

[oliverdunk]

We are moving forward with this change in Chrome: https://developer.chrome.com/blog/bfcache-extension-messaging-changes. Given the potential for breakage and the fact that this is not currently the behavior in Firefox, we are doing so cautiously and with warnings in DevTools to try and give time for extensions to adapt.

[xeenon]

WebKit issue tracking this: https://webkit.org/b/270413

[Jack-Works]

Currently, we're listening to port.onDisconnected to reconnect (not pageshow event). Will our code continue to work?

[oliverdunk]

Currently, we're listening to port.onDisconnected to reconnect (not pageshow event). Will our code continue to work?

Good question! In Chrome, this depends on where you are listening to the event:

• In the background context, the event does fire, including with a new error message starting in Chrome 124 (commit).
• In the content script, we agreed with other browsers not to fire an event. There are some open questions around when that would fire and pageshow seemed to be a reasonable solution. If we see this causing issues longer term, it's something that we could discuss if we want to change.

[Jack-Works]

In the content script, we agreed with other browsers not to fire an event. There are some open questions around when that would fire and pageshow seemed to be a reasonable solution. If we see this causing issues longer term, it's something that we could discuss if we want to change.

So this means, my port will not receive a disconnect event and the next message cannot be sent? I don't think it's intuitive to developers.