Add testcase for Js suspend issue from issue 813218 |
||||
Issue descriptionThis is to address the TODO in: https://chromium.googlesource.com/chromium/src.git/+/a07b7fdb2a948e91621bf13933bad9bb69b97520 Chrome Version: (copy from chrome://version) M64 OS: (e.g. Win7, OSX 10.9.5, etc...) all What steps will reproduce the problem? (1) join a g.co/present/some-name video call from a G Suite account (2) screencast a video window (3) make the screencaster window not in focus / rendering, i.e. look at the screencasted window or bring some other window in focus, such as news.google.com What is the expected result? screencaster can stay in the background, screencasting, indefinitely What happens instead? The Javascript on the screencaster tab stops running; the screencaster eventually gets kicked out of the meeting by the backend. Please use labels and text to provide additional information. For graphics-related bugs, please copy/paste the contents of the about:gpu page at the end of this report.
,
Mar 7 2018
The postmortem go/present-m64-regression (on corp) is ready to review. Thanks.
,
Mar 13 2018
,
Mar 13 2018
Let's start with adding a unit test for this on the scheduler side. It would be great to have an end-to-end test that actually runs a video call, but I don't think our test infrastructure (telemetry) is capable of recording and replaying WebRTC traffic.
,
Mar 13 2018
Would it be possible to simulate this scenario in a browser test using loopback peer connections? This is not the first bug we have had when presenting tabs are inactive.
,
Mar 15 2018
Hi, Can you please explain the M64 regression and/or make public Issue 813218? My team noticed that, when screen-sharing or viewing screen-shares in video chats with VP8 simulcast enabled (and high CPU usage), placing the video chat tab in the background apparently led to timers being throttled. One of these timers is supposed to keep our signaling connection alive. Because the timer was throttled, the users connected to the video chat in a background tab would be disconnected. Is it possible this issue caused this? Thanks, Mark
,
Apr 2 2018
+Webrtc folks. We do have a webrtc Telemetry benchmark using static HTML content, not sure if we can add a test case that cover this case.
,
Apr 3 2018
Erik, your test case in https://chromium-review.googlesource.com/c/chromium/src/+/738040 was supposed to address this exact issue, right? However, it only works on Linux for now. We should fix it so it runs on all platforms.
,
Apr 3 2018
Re #4: Nope, you can't easily replay WebRTC traffic since it's real-time. I doubt you need that for something like this though. I think the test in #9 can effectively address it; screenshare from one tab to another and make sure the screenshare video keeps flowing even if the source tab is out of focus. Right? It gets trickier if the screenshare needs to run a while for the issue to reproduce, though. Suggested actions: 1) make Erik's test run for all platforms 2) ensure it really catches the issue. If necessary, rewrite it to run for ~10s and make sure video flows continually. Is there any easy way to re-introduce the issue so we can test if the test really works?
,
Apr 3 2018
Right, the purpose of that test was to find background de-prioritization issues. Would be great if we could enable it on other platforms, win 7 seems to be a bot issue. I think the Mac issue was a thread checker that has now been fixed, so maybe that's OK to go right now. As stated, this test shuts down after receiving a single frame (the previous bug prevented video altogether). We should also double-check bot settings to make sure it is even able to repro (I think the bot runs with --single-process or something like that). Unfortunately I have no clock cycles to spare at the moment. :( |
||||
►
Sign in to add a comment |
||||
Comment 1 by q...@chromium.org
, Mar 7 2018