When reopening a closed tab, dynamic iframes in the page use cached data that does not fully match their src attribute
Reported by
bog...@oriel.io,
Oct 6 2017
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Steps to reproduce the problem: 1. Open the attached file in Chrome, with at least one other tab open. 2. Watch the alert, it shows the bing.com url that the iframe should load. 3. It works properly (meaning it searches for the string in the previous alert). 4. Close the tab. 5. Reopen Closed tab. 6. Notice the alert says it should now search in the bing iframe for something else. 7. Even though the DOM shows the iframe with the correct src (a different one!), the browser seems to show the old (previously cached?) content in the iframe. What is the expected behavior? After reopening the tab, a new bing search should appear. What went wrong? Iframe content didn't change, even though the src changed. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 61.0.3163.100 Channel: stable OS Version: OS X 10.12.6 Flash Version:
,
Oct 9 2017
Tested the issue on mac 10.12.6 and Win-10 using chrome reported version #61.0.3163.100 and latest canary #63.0.3236.0. Following are the steps followed to reproduce the issue. ------------ 1. Opened the attached file in Chrome, with at least one other tab open. 2. It showed as "You should see this URL on the page http://www.bing.com/search?q=7af" 3. Closed the tab. 5. Reopened closed tab. 6. Observed that the alert showed as "You should see this URL on the page http://www.bing.com/search?q=7af" Attached a screen cast for reference. Reporter@ - Could you please verify the screen cast and please let us know if it is the issue? Thanks...!!
,
Oct 9 2017
@krajshree, you have reproduced the issue The last alert in your video says you should see a search for `q1q` after reopening the tab. However, the iframe STILL shows you a search for 74v. If you would've inspected element, you would've seen that the second time around, the iframe's src was http://www.bing.com/search?q=q1q However, the content of the iframe seems to be incorrectly restored. If this is still not clear of if you have any more questions, don't hesitate to ask.
,
Oct 9 2017
Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 10 2017
Able to reproduce this issue on Mac 10.12.6, Win-10 and Ubuntu 14.04 using chrome reported version #61.0.3163.100 and latest canary #63.0.3236.0. This is a non-regression issue as it is observed from M50 old builds. Hence, marking it as untriaged to get more inputs from dev team. Thanks...!!
,
Oct 10 2017
The problem is confirmed, and this has nothing to do with DOM internals. I'd classify this as browser's session restore and <iframe> element.
,
Oct 13 2017
,
Feb 2 2018
Hi all, any updates on this?
,
Feb 2 2018
Does this still repro in M64 or later? FWIW, this seems quite similar to issue 500260 which was fixed by commit 6b4a0128... which initially landed in 64.0.3264.0
,
Feb 2 2018
I can't reproduce it anymore in v64. It seems to have been fixed, indeed. Good job!
,
Feb 2 2018
,
Feb 2 2018
Same thing here. Can't reproduce it anymore in V64. Thanks for your support! |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by bog...@oriel.io
, Oct 6 2017