New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 773324 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Display:None causes iframe that contains embed to not load properly

Reported by jjfranko...@gmail.com, Oct 10 2017

Issue description

UserAgent: 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:
 
Labels: Needs-Triage-M61

Comment 2 by junov@chromium.org, Oct 11 2017

Components: -Blink Blink>HTML>IFrame
Status: Untriaged (was: Unconfirmed)
Confirmed repro on M61

Comment 3 by dcheng@chromium.org, Oct 11 2017

Cc: erikc...@chromium.org joelhockey@chromium.org dcheng@chromium.org
Labels: Needs-Bisect
Labels: -Type-Bug -Pri-2 -Needs-Bisect hasbisect-per-revision ReleaseBlock-Stable M-62 OS-Linux OS-Mac Pri-1 Type-Bug-Regression
Owner: gmanikpure@chromium.org
Status: Assigned (was: Untriaged)
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...!!
Status: WontFix (was: Assigned)
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