Issue metadata
Sign in to add a comment
|
Regression: Video stuck and seek bar continues to progress after detaching and merging current tab. |
||||||||||||||||||||||
Issue descriptionChrome Version: 72.0.3626.7 (Official Build)efcef9a3ecda02b2132af215116a03852d08b9cb-refs/branch-heads/3626@{#63}(32/64 Bit) OS: Windows(7,8,8.1,10). Test URL: https://mounirlamouri.github.io/sandbox/media/dynamic-controls.html What steps will reproduce the problem? 1. Launch chrome, open one NTP and navigate to the above test url in another NTP. 2. Play the video and drag video progress bar to nearly half. 3. Right click on 3-Dot menu and select Picture-In-Picture option. 4. Again click on 3-Dot menu and Exit Picture-In-Picture window. 5. Now detach and merge current tab twice. 6. Observe. Actual Result: Video stuck and seek bar continues to progress after detaching and merging current tab. Expected Result: Video should not stuck after step 5 and should go along the progress bar. This is a regression issue, broken in M-71 series, and will soon provide bisect info: Good Build: 71.0.3557.0(Revision:592638) Bad Build: 71.0.3558.0(Revision:593042) Kindly refer the screen-cast from the link given below Note: 1. Issue is Windows (7,8,8.1,10) OS specific and is not seen on Mac(10.13.1, 10.13.6, 10.14.2), Linux(14.04 LTS) OS. 2. Issue is also seen on Stable #71.0.3578.80 Beta #71.0.3578.80 and Latest Canary #73.0.3630.0 build. Thank You!
,
Dec 5
Changing the status to Untriaged so that the issue would get addressed. Thank You!
,
Dec 6
,
Dec 7
lethalantidote@, this sounds like a VideoSurfaceLayer regression as when we toggle Picture-in-Picutre we turn on surface layers. I was able to repro on Linux Dev 72.0.3610.2
,
Dec 7
,
Dec 7
i can also repro. to add some detail: - seeking isn't needed. - video plays when detached, only stops playing when tab is reparented.
,
Dec 8
Some more details I found: - This happens when the SurfaceLayerMode is set to Always. - I actually see the video freeze when I detach, not just when reparented. It also does not happen consistently for me either way. (sometimes I can both detach and reparent without error). Still looking into this, but adding notes here in case it sparks an idea.
,
Dec 10
,
Dec 10
I'm seeing x11_util.cc(1426)] X error received: serial 775, error_code 3 (BadWindow), request_code 4, minor_code 0 (Unknown)
,
Dec 11
Given that the issue also happens on Windows, this is most likely a red herring.
,
Dec 11
,
Dec 11
+fsamuel@ We've tracked this down to the Submitter being stuck on waiting for a compositor ack. This only happens if we have PiP'ed, it doesn't occur on just videos with surface layer enabled. In both cases, the SurfaceId is updated by Layer:SetShowSurface when we reparent. I am unaware of what PiP could be doing to change things such that the Submitter no longer gets these compositor acks. Adding Fady onto this, as they might have some insight in to what could prevent us seeing a DidReceiveCompositorFrameAck call.
,
Dec 12
FWIW, this is also reproducible on Chrome 71.
,
Dec 22
,
Jan 3
+samans, who has been working on the SurfaceLayerBridge. Do you think you could address the concern outlined in comment 12?
,
Jan 4
So I noticed that seeking after the freeze fixes it. Have you investigated why this happens? Because I don't think seeking can force viz to send an ack.
,
Jan 5
When one seeks, it causes a frame to be sent (we stop rendering and that sends out a frame). This causes all the previous DidReceiveCompositorFrameAcks to get returned to us for some reason, as almost like a flush. I don't know whats keeping the DidReceiveCompositorFrameAck from returning otherwise. Additional Note: Does not seem to repro on ChromeOs...
,
Jan 5
I'll pick this up.
,
Jan 8
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2886e0adfb9818eb12ac63c6bae9395d4c6c78cd commit 2886e0adfb9818eb12ac63c6bae9395d4c6c78cd Author: Saman Sami <samans@chromium.org> Date: Tue Jan 08 21:39:40 2019 Fix video stuck after tab reparenting Currently a display only acks surfaces that it hears about via SurfaceDamaged, but there is no call to SurfaceDamaged for surfaces that are being embedded for the first time. That means if Display A goes invisible before it gets a chance to ack a surface, and then this surface gets embedded by Display B, since there is no call to SurfaceDamaged in Display B, the surface never gets acked and appears stuck. Make sure we ack all surfaces embedded by the display, and not just the ones received in SurfaceDamaged. Bug: 912000 Change-Id: I027a5ac37b8c6e564f008a871ca1ec8ad0190733 Reviewed-on: https://chromium-review.googlesource.com/c/1400943 Reviewed-by: kylechar <kylechar@chromium.org> Commit-Queue: Saman Sami <samans@chromium.org> Cr-Commit-Position: refs/heads/master@{#620889} [modify] https://crrev.com/2886e0adfb9818eb12ac63c6bae9395d4c6c78cd/components/viz/service/display/display.cc [modify] https://crrev.com/2886e0adfb9818eb12ac63c6bae9395d4c6c78cd/components/viz/service/display/display.h
,
Jan 8
,
Jan 9
Update: Retested the above issue on Windows (7,8,8.1,10) and Linux(14.04 LTS) OS using latest Canary build #73.0.3666.0 and issue is fixed. Now, Video does not stuck when the tab is attached/detached from browser. Kindly find below the attached screen-cast for reference. Thank You! |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by aim...@virtusa.com
, Dec 5