port.onDisconnect does not seem to fire in an extension's background page after a connected port is abandoned via an iframe reload
Reported by
lur...@hotmail.com,
Oct 14 2016
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.59 Safari/537.36 Steps to reproduce the problem: 1. have an extension with a background page that listens on content script ports 2. open a persistent port connection from a content script in an iframe to the background page 3. reload the iframe 4. see no port.onDisconnect fire, but see a new port connect from the new iframe instance What is the expected behavior? I would expect that the iframe reload would fire the port.onDisconnect method, as happens when you close the tab containing the iframe. What went wrong? I have a chrome extension that has content scripts that communicate with the extension's background page both from the main window and from an embedded iframe. If the entire window closes, both connections fire the port.onDisconnect method in the extension's background page. If I reload the iframe manually via the chrome context menu on that frame, the old port from the iframe does not fire the port.onDisconnect method in the extension background page. The same seems to be true for a programmatic reload (window.location.href = window.location.href, etc.) of the iframe. The new iframe instance triggers a new instance of the content script to run, which in turn creates a new connection to the background page, but that old iframe's port is in limbo, even though it is no longer accessible. I'm fairly sure this behaviour used to work. It seems to have stopped working somewhere around v52 or so. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 54.0.2840.59 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 23.0 r0
,
Nov 6 2016
If you can attach a simple test case html and a simple extension that reproduces the issue it will increase the chances of the issue being fixed...
,
Nov 7 2016
Probably more an extensions issue rather than a blink messaging issue, so updating the component to hopefully get it triaged better.
,
Dec 21 2016
Confirming same issues with port.onDisconnect for the Mailvelope Chrome extension.
,
Dec 26 2016
Issue 676972 has been merged into this issue.
,
Jan 5 2017
I've actually just run into this issue as well, and would love a fix. I was about to enter my own ticket for it but found this one so I will share my test case here.
-- EXTENSION --
background.js:
chrome.runtime.onConnect.addListener(function (port) {
port.onDisconnect.addListener(function () {
console.debug('Disconnected: ' + port.sender.url);
});
});
contentScript.js:
chrome.runtime.connect();
manifest.json:
"content_scripts": [{
"matches": [
"http://*/*",
"https://*/*",
"file:///*"
],
"js": ["contentScript.js"],
"all_frames": true,
"run_at": "document_start"
}]
-- WEB PAGE --
test.html:
<!DOCTYPE html>
<html>
<body>
<iframe src='test2.html'></iframe>
</body>
</html>
test2.html:
<!DOCTYPE html>
<html>
<body>
<script>
window.addEventListener('beforeunload', function() {
console.log('Unloading: ' + window.location.href);
})
if (/test2\.html$/.test(window.location.href)) {
window.location.href = window.location.href + '?test=1';
}
</script>
</body>
</html>
Steps to recreate:
1. Load test.html
2. Inspect the background page and see that the disconnect was not fired for the test2.html iframe.
3. Once you refresh the page you will see that all allocated ports are finally disconnected
Expected behavior:
The port associated with the iframe "test2.html" should be disconnected as soon as the JS redirect happens.
,
Jan 6 2017
For anyone interested, a workaround for this issue is to manually call port.disconnect() from the content script when the beforeunload/unload event is fired in the iframe:
window.addEventListener('unload', function() {
port.disconnect();
});
,
Feb 13 2018
Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||
►
Sign in to add a comment |
|||
Comment 1 by lur...@hotmail.com
, Nov 5 2016