Issue metadata
Sign in to add a comment
|
Embedly video below the fold renders only partial iframe
Reported by
v...@webflow.com,
Sep 5
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.81 Safari/537.36 Example URL: https://codepen.io/afoon/pen/MqoBoE Steps to reproduce the problem: 1. Load https://codepen.io/afoon/pen/MqoBoE (or ) 2. Quickly scroll down via trackpad What is the expected behavior? The entire video should show, as does correctly in Chrome 68: https://cl.ly/f37e63301035 What went wrong? The video is cut off and only a few pixels of the top part of the video is show shown: https://cl.ly/09d687f8dd44 Does it occur on multiple sites: Yes Is it a problem with a plugin? N/A Did this work before? Yes v68 Stable Does this work in other browsers? N/A Chrome version: 69.0.3497.81 Channel: stable OS Version: OS X 10.13.6 Flash Version: Also able to reproduce when scrolling https://www.reddit.com/r/video/ quickly, which doesn't use Embedly, but has similar double-iframe embeds: https://cl.ly/a56facf2a62f
,
Sep 5
,
Sep 5
I've reproduced this in Mac 69.0.3497.81 stable, but it behaves as intended in Mac 71.0.3542.0 Canary, and I also saw it working in an earlier Mac M70 Canary. This is definitely not a LazyLoad bug, as the OP originally mentioned on twitter, since LazyLoad couldn't cause this kind of behavior where iframes are only partially shown on the screen. Plus, LazyLoad is still currently in the experimental phase in Dev channel, and it certainly isn't currently enabled on any Stable or Desktop versions. It does somewhat seem like there could be a problem somewhere else in the pipeline, maybe somewhere before the frame gets drawn that might cause only a partial slice of the iframe to be drawn, but I'm not an expert on that part of Blink. I'm tentatively adding the Blink>Compositing component in the hope that someone who's more familiar with this part of Blink can take a look and see what's going on here.
,
Sep 5
vlad@ Thanks for the issue. Able to reproduce this issue on Windows 10, Mac OS 10.13.3 and Ubuntu 17.10 on the latest Stable 69.0.3497.81 by enabling the flag #enable-site-per-process. Issue seems to be fixed on the latest Canary 71.0.3542.0. Revert Bisect Information: ========================== Good Build: 70.0.3506.0 Bad Build : 70.0.3505.0 By running per-revision bisect script, RunTimeError was coming up. Hence by running Chromium bisect below is the Changelog URL. https://chromium.googlesource.com/chromium/src/+log/6e051039df09c5244e77bf3a5a6b4570e23696fd..83a3440044a5789b4525799c9da72d0f51ab6fcc From the above Changelog, suspecting the below change: Reviewed-on: https://chromium-review.googlesource.com/1153838 kenrb@ Please check and confirm if this issue is related to your change, else help us in assigning to the right owner. Adding 'ReleaseBlock-Stable' for M-69 as this is a recent regression. Please feel free to remove if it is not applicable. Thanks
,
Sep 5
Potential duplicate: https://bugs.chromium.org/p/chromium/issues/detail?id=880673
,
Sep 5
,
Sep 5
Should this issue be merged into https://bugs.chromium.org/p/chromium/issues/detail?id=868558?
,
Sep 5
I can confirm that this is a dupe of issue 868558 . Comment #4 blames r578922 for the behavior but I think that is backwards, because that CL fixed it. On trunk I have confirmed that reverting that CL regresses this bug once again. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by gov...@chromium.org
, Sep 5