-
Notifications
You must be signed in to change notification settings - Fork 56
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Behaviour of extension message ports and bfcache #474
Comments
@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? |
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. |
WebKit issue tracking this: https://webkit.org/b/270413 |
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:
|
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. |
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.
The text was updated successfully, but these errors were encountered: