Display:None causes iframe that contains embed to not load properly
Reported by
jjfranko...@gmail.com,
Oct 10 2017
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Steps to reproduce the problem: 1. Review this simple source of the example which works fine when not in an iframe and adds the "zoom" widget for an "<object>" svg when the window.onload is fired: http://ariutta.github.io/svg-pan-zoom/demo/object.html 2. Review this code pen of the same page within an iframe in chrome where the "zoom widget" no longer gets loaded because of the 'display: none' added to the body". Notice that other browsers like firefox and IE11 work fine and load the "zoom widget" properly. https://codepen.io/blueShell/pen/GMdPVz?editors=1111 2. Review this code pen of the same page within an iframe in chrome where the "zoom widget" gets loaded because we used 'visibility hidden' instead of 'display: none' and the zoom widget is properly shown in chrome. https://codepen.io/blueShell/pen/oGdJyo?editors=1111 What is the expected behavior? I would expect the zoom widget to always be visible and he embedded's What went wrong? It seems that if the <object> svg is in part of the html document this has "display: none" in its dom element ancestory, then the "window.load" fires BEFORE the embedded object have loaded. So it seems the page is firing the load event before the <object> is fully loaded. The other weird side affect of having an <object> in a 'display: none' ancestry is that when it becomes visible with 'display:block' then the tiger.svg will be retrieved a second time for each element. This seems pretty inefficient. (You can confirm this with the network tab. This is not a problem for the visible: hidden.) Did this work before? N/A Chrome version: 61.0.3163.100 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version:
,
Oct 11 2017
Confirmed repro on M61
,
Oct 11 2017
,
Oct 12 2017
Able to reproduce the issue on Mac 10.12.6, Win-10 and Ubuntu 14.04 using chrome reported version #61.0.3163.100 but the same is not reproducible in the latest canary #63.0.3237.7. Reverse Bisect Information: ===================== Good build: 62.0.3196.0 Revision(497279) Bad Build : 62.0.3194.0 Revision(496533) Change Log URL: https://chromium.googlesource.com/chromium/src/+log/45d6f2d8ece330462a5e1964cc97900c233480dd..b346e16a2e6b8a1e718e59da71deac5943a7b948 From the above change log suspecting below change Change-Id: I831a1cea0697e283772f109d171110f3f93e0e89 Reviewed-on: https://chromium-review.googlesource.com/622159 gmanikpure@ - Could you please check and merge the fix to M-62 if it is a valid candidate. Note: Adding label ReleaseBlock-Stable as it seems to be a recent regression. Thanks...!!
,
Oct 12 2017
Latest M62 Beta#62.0.3202.52 is working fine, so next M62 stable should have this fixed which is going to release next week to the public. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by ligim...@chromium.org
, Oct 10 2017