Issue metadata
Sign in to add a comment
|
Video preview still images not fully rendered depending on scroll rate
Reported by
m...@mikefarr.ca,
Sep 7
|
||||||||||||||||||||||||
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://www.reddit.com/r/games Steps to reproduce the problem: 1. Open https://www.reddit.com/r/games, select "Card" view. 2. Scroll down until at least one embedded YouTube video preview should be in the frame. What is the expected behavior? Embedded video preview still image should be fully rendered. What went wrong? The preview still image is only partially rendered, with empty white space filling the rest of area used by the embedded video. The amount of the preview image that is rendered depends on how quickly it scrolls into the frame - faster scrolling results in more of the image being rendered. The top or bottom of the image is rendered depending on the direction of the scrolling. The video plays and is rendered correctly when clicked. See attached screenshot for example. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? Yes 68 Does this work in other browsers? Yes Chrome version: 69.0.3497.81 Channel: stable OS Version: OS X 10.13.6 Flash Version: This behaviour can be reproduced on other pages with embedded video previews, but it does not happen for all videos. For example, the video in the embedded Tweet at https://www.cbc.ca/news/canada/hamilton/shooting-st-catharines-1.4813465 exhibits the behaviour, but the embedded video above it renders correctly.
,
Sep 7
Actually I take that back, running in linux with --force-device-scale-factor=2 I was able to reproduce and bisect the issue to the following range: https://chromium.googlesource.com/chromium/src/+log/81cadf27a8206ec3926cf170ff11840f6651e499..cdea59c0db145f8e85ea00e9f6d31642929e2397 Chris, https://chromium.googlesource.com/chromium/src/+/cdea59c0db145f8e85ea00e9f6d31642929e2397 looks likely, can you have a look?
,
Sep 7
I can confirm that opting out of site isolation resolves the issue, and re-enabling it causes it to appear again. I can also reproduce in Windows.
,
Sep 11
Marking as p1 and releaseblock since IO is very important to get right, so we should merge a fix to M70 if possible.
,
Sep 11
,
Sep 11
I can't reproduce this with the steps in comment #2. I'm running version 69.0.3497.92 (beta) on Linux, with these flags: --site-per-process --force-device-scale-factor=2 flackr@, any suggestions? I have a couple of CL's in the pipeline that might address this, but I don't know how to test it.
,
Sep 12
I am no longer able to reproduce this issue in either MacOS or Windows with version 69.0.3497.92. It seems to be resolved, at least as far as I can tell.
,
Sep 12
This issue is marked as a release blocker with no milestone associated. Please add an appropriate milestone. All release blocking issues should have milestones associated to it, so that the issue can tracked and the fixes can be pushed promptly. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 17
szager, could you please verify that this has been fixed (as described in comment 7)?
,
Sep 17
szager could never reproduce. flackr@, could you verify?
,
Sep 17
This issue is marked as a release blocker with no milestone associated. Please add an appropriate milestone. All release blocking issues should have milestones associated to it, so that the issue can tracked and the fixes can be pushed promptly. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 24
This seems to have been fixed. Here's the reverse bisect I did locally: https://chromium.googlesource.com/chromium/src/+log/6e051039df09c5244e77bf3a5a6b4570e23696fd..83a3440044a5789b4525799c9da72d0f51ab6fcc I would guess that eb3c53e64b63a74417d11b566c24081e5f386eb9 fixed it but that wouldn't be until version 70.0.3506.0. Nevertheless this should be fixed in M70. Ken, was this patch (or some form of it) merged back to M69?
,
Sep 24
Yes the fix was merged to M69 and should be on 69.0.4397.85 or later. I see the original report was on 69.0.3497.81, but there was an early Stable respin. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by flackr@chromium.org
, Sep 7