New issue
Advanced search Search tips

Issue 880673 link

Starred by 5 users

Issue metadata

Status: Duplicate
Merged: issue 868558
Owner: ----
Closed: Sep 5
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 3
Type: ----



Sign in to add a comment

Critical failure with lazyload, breaks all nested iframes

Reported by c...@medium.com, Sep 5

Issue description

Device name:

From "Settings > About Chrome"
Application version: Version 69.0.3497.81 (Official Build) (64-bit)
Operating system: OSX

URLs (if applicable): https://www.reddit.com/r/videos, https://embed.ly/docs/explore/oembed?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DWgLSXLs5ZYc

Steps to reproduce:
(1) Load any nested iframe below or partially below the fold
(2)
(3)

Expected result: Frame should render completely

Actual result: Frame is partially rendering. Chrome only renders either a sliver, or the portion of the frame that was above the fold.

I work on embeds at Embedly, an API used by many large content providers (salesforce, reddit, medium.com, etc)  This is a critical bug that will affect a large surface area of the internet.  Our guess is that lazyload for iframes you have added in this version of Chrome (69) does not work at all for nested iframes, which is a very common practice for caching and other security purposes across the web. (inspect the iframe at https://embed.ly/docs/explore/oembed?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DWgLSXLs5ZYc for an example of what I mean by a nested iframe)

Fastest way to reproduce is to just visit https://reddit.com/r/videos in Chrome v69 and expand a video by clicking the play button on a reddit link, such that the embed will fill partly below the fold of the page. The iframe will only render the portion that was visible when the button was clicked, and even after scrolling the rest of the frame into the view, it doesn't render. 

Please email me at cs@medium.com if you need to get a hold of me.
 
Screen Shot 2018-09-04 at 10.50.20 PM.png
1.2 MB View Download
Screen Shot 2018-09-04 at 10.50.44 PM.png
1.7 MB View Download
Screen Shot 2018-09-04 at 10.50.55 PM.png
860 KB View Download
Just to be clear, this is an issue on the Desktop version of Chrome, not Android as categorized above.
Cc: pbomm...@chromium.org ajha@chromium.org
Labels: -OS-Android Needs-Triage-M69 OS-Mac
Disabling chrome://flags/#enable-lazy-frame-loading doesn't fix the bug so it doesn't seem related to lazy-load.

Bisected to https://chromium.googlesource.com/chromium/src/+log/8082fb9c..cdea59c0?pretty=fuller
Suspecting cdea59c0db145f8e85ea00e9f6d31642929e2397 = https://crrev.com/c/1134348 by chrishtr@chromium.org
"[IO] Only compute intersection observations if any property tree state has changed, and only for full-frame updates."

Arguably this should have affected millions of users even in the non-stable channels so apparently people got used to the non-stable channel being buggy and just expect the bugs to magically disappear in the stable channel or maybe they blame the sites for the rendering artifacts...
This bug is fixed in Chrome 70 by r578922 ( issue 868558 ).
The fix wasn't merged into Chrome 69.

A temporary workaround is to choose "opt out" in chrome://flags/#site-isolation-trial-opt-out
Or run chrome with "--disable-site-isolation-trials" in the command line.
N.B. Disabling site isolation weakens security.

Cc: gov...@chromium.org
Components: Internals>Sandbox>SiteIsolation
Labels: Triaged-ET ReleaseBlock-Stable OS-Linux OS-Windows
Mergedinto: 868558
Status: Duplicate (was: Unconfirmed)
Able to reproduce the issue on Mac 10.13.3, Win-10 and Ubuntu 17.10 using chrome reported version #69.0.3497.81 but the same is not reproducible in the latest canary #71.0.3542.0.
The issue looks similar to the issue id: 868558. Adding RBS for M-69 for tracking purpose to the issue id: 868558 and duping into it.

Thanks...!!
Cc: kenrb@chromium.org creis@chromium.org
Labels: M-69 Target-70 Target-71 M-71 M-70 Target-69

Sign in to add a comment