Iframe not being rendered
Reported by
maks.t...@gmail.com,
Jun 12 2017
|
|||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36 Steps to reproduce the problem: 1. Login to https://surfly.com/app with the following credentials: yauhen+chrome@surfly.com / chrometest 2. Go to the Start page and start a cobrowsing session to http://x.zok.pw/chrometest/test.html 3. Observe the content from test.html appear 4. Copy the link from the address bar and open it in another window (preferably isolated, Incognito tab will do) 5. Observe that the content doesn't show up in the new window. If it does show up, try to refresh the page a couple of times. What is the expected behavior? The content should be shown on the follower side as well What went wrong? The iframe on the follower side (the second window) does not render, eve though the HTML is there. Did this work before? N/A Chrome version: 59.0.3071.86 Channel: stable OS Version: OS X 10.12.5 Flash Version: I've recorded a video of how to reproduce the issue: https://www.useloom.com/share/cb6c79b739484ceeba1ca813e69acdd9 I suspect this is similar to https://bugs.chromium.org/p/chromium/issues/detail?id=718358, although it is triggered by other circumstances, and it is not fixed in Chrome Canary. Note that the bug is only reproducible when the page is navigated via Surfly, which is a smart sandboxing proxy, so it does add some extra stuff. However, this works in Safari and FF, and I don't see any reasons why it shouldn't work, so I use it's a bug in Chromium. Sorry for quite a complex steps to reproduce, I tried to minify it as much as possible. I am a developer at Surfly, so feel free to ask if you need more details.
,
Jun 14 2017
Able to reproduce on Windows-10, Ubuntu 14.04 and Mac OS 10.12.5 using chrome latest stable #59.0.3071.86. Bisect Information: -------------------- Good build: 56.0.2916.0 Bad Build : 56.0.2918.0 You are probably looking for a change made after 431728 (known good), but no later than 431729 (first known bad). Change Log URL: https://chromium.googlesource.com/chromium/src/+log/d906307326c3dc389cd5d9632ee6d7ca51430303..e6c90470f20ec3d83f0f8b95c2943885c1b0f69a From the above change log suspecting below change Review-Url: https://codereview.chromium.org/2488213005 esprehn@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Thanks!
,
Jun 15 2017
,
Oct 19 2017
The assigned owner "rune@opera.com" is not able to receive e-mails, please re-triage. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 19 2017
,
Oct 20 2017
Since this bug was created, we implemented a workaround, so it's not reproducible on our production server at the moment. I'll try to describe what happens and I still believe it is very similar to https://bugs.chromium.org/p/chromium/issues/detail?id=718358. What seems to trigger the bug is when there are <link> tags BOTH in head and in the body (that's what you see in the test page http://x.zok.pw/chrometest/test.html). When we construct such a page programmatically inside a deeply nested iframe, Chrome doesn't render it. Probably has to do with rendering optimizations.
,
Nov 8 2017
,
Nov 30 2017
,
Nov 30
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 30
|
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by nyerramilli@chromium.org
, Jun 12 2017