Back button messes up SVG in <object> tags
Reported by
konrad.d...@gmail.com,
Mar 10 2016
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36 Example URL: http://konradpapala.beep.pl/test/ Steps to reproduce the problem: 1. have multiple svg loaded via <object> on a page 2. Refresh the page (yes, it's important for some reason) 3. leave the page 4. press back button to go back to page 5. if everything's fine, repeat. Sooner or later the bug will appear (rather sooner than later) What is the expected behavior? All svgs should still be in place What went wrong? They are not. They are swapped. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 48.0.2564.109 Channel: stable OS Version: Ubuntu/KDE Flash Version: Shockwave Flash 20.0 r0 Giving the <object> tags unique names "solves" the issue. Maybe this is a clue.
,
Mar 16 2016
Confirmed. This is bad. The HTMLPluginElement::loadOrRedirectSubframe() method is invoked the same number of times for each type of images even when imbalanced (e.g. 4 papers vs. 2 pencils). I guessed that premature frame identifier is generated when the name attribute is not specified and because of that frame is attached to incorrect element, but not sure...
,
Mar 16 2016
The URL of a child frame was overridden at WebLocalFrameImpl.cpp:1613 [1]. [1] https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/Source/web/WebLocalFrameImpl.cpp#1604
,
Mar 18 2016
Thanks tzik@. I did further investigation. The root cause it that calculateUniqueNameForChildFrame() generates a unique identifier based on the order it's called. FrameView::updateWidgets() iterates over embedded objects by iterating over a HashSet containing them. This doesn't happen to <iframe> which uses the same class HTMLFrameOwnerElement since it calls loadOrRedirectSubframe() in the order it's inserted.
,
Mar 18 2016
Cont'd. Therefore, when WebLocalFrameImpl::createChildFrame() attempts to retrieve the contents to show in a frame after back/forward navigation happened, it passes a different uniqueName to WebFrameClient::createChildFrame() to get an incorrect info. The uniqueName is generated right before the call by using calculateUniqueNameForNewChildFrame().
,
Mar 18 2016
One possible quick fix is to have HTMLPluginElement override didNotifySubtreeInsertionsToDocument() and calculate a uniqueName in it to align with what <iframe> is doing. japhet@, does this make sense?
,
Mar 18 2016
I think so, but it'a been a while since I've dealt with the back/forward name stuf.
,
Apr 22 2016
,
Apr 24 2017
This issue has been available for more than 365 days, and should be re-evaluated. Please re-triage this issue. The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 24 2017
I could not get this to repro in M-58 linux. Could someone else please try and close the bug if it no longer reproduces.
,
Apr 25 2017
Can no longer reproduce. Reopen if the problem recurs. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by tkent@chromium.org
, Mar 10 2016