Closed Bug 1672623 Opened 4 years ago Closed 4 years ago

Closing the picture-in-picture window pauses the cloned video element which is questionable for video conferences

Categories

(Toolkit :: Video/Audio Controls, defect)

defect

Tracking

()

VERIFIED FIXED
85 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox83 --- wontfix
firefox84 --- verified
firefox85 --- verified

People

(Reporter: cfogel, Assigned: jack1391)

References

(Blocks 1 open bug, )

Details

(Keywords: regression)

Attachments

(1 file)

Affected versions

  • 84.0a1(2020-10-21); 83.0b2;

Affected platforms

  • macOS 11.0, macOS 10.15;

Steps to reproduce

  1. Launch Firefox on 2 instances;
  2. Connect with 1 valid Facebook account in each;
  3. Perform a call between the 2;
  4. From any call window enable PIP;
  5. Close the PIP window;

Expected result

  • call is working ok;

Actual result

  • audio-video feed stop;

Regression range

  • will check and provide one asap;

Additional notes

  • S3 as suggested severity since the call needs to be re-set in order to work;
  • calls between Windows10 - macOS have the same issue only when closing the PIP on macOS.
Has Regression Range: --- → no
Has STR: --- → yes
QA Whiteboard: [qa-regression-triage]

ni? myself to have a look

Flags: needinfo?(apehrson)

Hello! I have managed to find the regression range of this issue with the STR provided in the description. The calls have been made between MacOS 10.15 and Windows 10.
Here is the regression pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9f3fcb6752b4e36779e395abef8362f0b0d14e7b&tochange=cad2c16785936bd362cc7f19ad521d2a1db1bb79

Has Regression Range: no → yes

(In reply to Negritas Sergiu from comment #2)

Here is the regression pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9f3fcb6752b4e36779e395abef8362f0b0d14e7b&tochange=cad2c16785936bd362cc7f19ad521d2a1db1bb79

Well that includes bug 1653496 which enabled PiP for MediaStream playback in the first place, so not the real regressor. This is something latent I guess, probably timing related since it's mac only.

Simpler STR (reproduces on both mac and linux):
1 Load https://mozilla.github.io/webrtc-landing/gum_test.html
2 Click Camera
3 Approve permission prompt, if any
4 Once video is live, right click video element and click picture-in-picture
5 Close the pip window with the X in the top right corner

Expected: video is still live
Actual: video is frozen

Flags: needinfo?(apehrson)

Doing this for Camera+Microphone shows that audio playback freezes too.

OS: macOS → Unspecified
Summary: [mac] Stopping PIP on Facebook call freezes video+audio on 1 side → Stopping PIP on video MediaStreamTrack freezes MediaStream playback

So PictureInPictureChild calls pause() on the media element when closing the pip-window. See my notes in the notebook in the pernosco recording.

Pausing on close is one of the things that doesn't translate well from playback (youtube et al) to realtime (video conf). Mike, FYI.

Component: WebRTC → Video/Audio Controls
Flags: needinfo?(mconley)
Product: Core → Toolkit
Summary: Stopping PIP on video MediaStreamTrack freezes MediaStream playback → Closing the picture-in-picture window pauses the cloned video element which is questionable for video conferences

Hey Chris, perhaps you could look at this? I think we'd want to change the behaviour of this message here: https://searchfox.org/mozilla-central/rev/96e2c6e14998f38e419850d55d8a3d32a3fc244a/toolkit/components/pictureinpicture/content/player.js#298

Instead of pausing unilaterally, let's pass an object along with it to say that we want to pause specifically because the user has closed the player window. In the receiving side of that message, we should check to see if the associated video has a non-null srcObject property, and if so, skip pausing.

Blocks: videopip, 1662870
Flags: needinfo?(mconley) → needinfo?(jack1391)

Note that by spec srcObject is not necessarily a MediaStream. It happens to be in Firefox at the moment, but expect that to change at some point. For non-MediaStream srcObjects we should maintain current behavior.

Thanks, pehrsons!

Assignee: nobody → jack1391
Status: NEW → ASSIGNED
Pushed by mconley@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/775b72d2e464
Closing PiP window pauses the cloned video element for video conferences. r=mconley
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 85 Branch

The patch landed in nightly and beta is affected.
:jack1391, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(jack1391)

Comment on attachment 9187019 [details]
Bug 1672623 - Closing PiP window pauses the cloned video element for video conferences. r?mconley,gijs

Beta/Release Uplift Approval Request

  • User impact if declined: When using PiP with video calling/conferencing tools, closing the PiP window breaks things in ways users can likely not recover from without ending and re-establishing the call
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: See comment #1 / comment 4
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): We're making an exception to pausing-when-closing PiP just for video call situations. The code change is pretty small and has good test coverage.
  • String changes made/needed: nope
Attachment #9187019 - Flags: approval-mozilla-beta?
Flags: qe-verify+
Flags: needinfo?(jack1391)
QA Whiteboard: [qa-regression-triage] → [qa-regression-triage][qa-triaged]

Verified as fixed on Firefox Nightly 85.0a1 (2020-11-24) on Windows 10 x64, Ubuntu 20.04 and on MacOS 10.15 following the steps from comment #1 / comment 4.

Comment on attachment 9187019 [details]
Bug 1672623 - Closing PiP window pauses the cloned video element for video conferences. r?mconley,gijs

approved for 84.0b5

Attachment #9187019 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Verified as fixed on Firefox 84.0b5 on Windows 10 x64, Ubuntu 20.04 and on MacOS 10.15 following the steps from comment 1 / comment 4.

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-regression-triage][qa-triaged]
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: