Fast switching the iframe "src" attribute sometimes does not change the content.
Reported by
babata...@gmail.com,
Feb 27 2018
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3356.0 Safari/537.36 Example URL: Steps to reproduce the problem: 1. Extract attached "testcase.zip". 2. (optional) Enable "CPU: 6x slowdown" in devtools performance tab. This makes it easier to reproduce. 3. Open "index.html". What is the expected behavior? The left iframe shows "Child page 2" and the right iframe shows "Child page 1". What went wrong? Sometimes (about once in five times, depends on machine spec) the iframes show incorrect content. Please see attached screenshot. Does it occur on multiple sites: N/A Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 66.0.3356.0 Channel: canary OS Version: 10.0 Flash Version: - Actually this issue also reproduce with one iframe, but harder to reproduce. - It seems hard to reproduce if the content of iframes are very small. "child1.png" in the testcase is included to increase the size.
,
Feb 28 2018
Unable to reproduce the issue on Win-10 and mac 10.13.3 using chrome reported version #66.0.3356.0. Attached a screen cast for reference. Following are the steps followed to reproduce the issue. ------------ 1. Extracted attached "testcase.zip". 2. Enabled "CPU: 6x slowdown" in devtools performance tab. 3. Opened "index.html". 4. Observed that the left iframe showed "Child page 2" and the right iframe showed "Child page 1" as expected. Note: Checked the issue 5 times. babatakao@ - Could you please check this issue on latest stable #56.0.2924.87 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not. Thanks...!!
,
Feb 28 2018
The issue still occurs on 66.0.3357.0. Please see this screencast: https://youtu.be/uWpfE4BgMZs - As I did in the screencast, I created a new profile and remove all extensions. - I've seen this issue on more than two different PCs. - The issue can reproduce on all of Canary(66), Beta(65) and Stable(64) Chrome. I hope these information are helpful. Thanks.
,
Feb 28 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 1 2018
,
Mar 1 2018
Confirmed. I guess it's because FrameLoader::CommitProvisionalLoad calls NavigationScheduler::Cancel. japhet@, is it a desired behavior?
,
Mar 1 2018
I think this is essentially WAI: if you race navigations like this, there is no guarantee which navigation request will end up cancelling (and potentially cancelling a subsequent navigation that's been requested but not yet ready to commit). See step 6 of the spec for navigation: https://html.spec.whatwg.org/multipage/browsing-the-web.html#navigate "Cancel any preexisting but not yet mature attempt to navigate browsingContext, including canceling any instances of the fetch algorithm started by those attempts. If one of those attempts has already created and initialized a new Document object, abort that Document also. (Navigation attempts that have matured already have session history entries, and are therefore handled during the update the session history with the new page algorithm, later.)"
,
Mar 7 2018
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by susan.boorgula@chromium.org
, Feb 27 2018