1608434 - Facebook - PIP - Play/Pause if not working first time watching a video in news Feed

Status: NEW

(Toolkit :: Video/Audio Controls, defect, P2)

Description

[Bogdan Maris [:bogdan_maris], Release Desktop QA]

Attachment: FB Feed defect 2020-01-10.mov

Affected versions

• Firefox 73.0b3
• Firefox 72.0.1
• Latest Nightly 74.0a1

Affected platforms

• macOS 10.15.3
• Windows 10 64bit

Unaffected platforms

• Ubuntu 16.04

Steps to reproduce

1. Launch Firefox.
2. Go to https://www.facebook.com/ and sign in.
3. Scroll down to a video or open Videos on Watch and play a video.
4. A small blue square toggle PiP (Picture-in-Picture) button is shown on the right side of the video. Click on the toggle.
5. Hover the mouse over the PiP window and check the controls (Pause, Play and Close).

Expected result

• Controls are working as expected.
• Video is Paused/Played accordingly

Actual result

• Pause/Play is not working accordingly in Facebook feed mode. If a user is in PIP mode and click for the first time Play/Pause button, video will not play.

Regression range

• as soon as possible I will search for a regression range if applicable

Additional notes

• reproducible only in feed mode/page

Comment 1

[Bogdan Maris [:bogdan_maris], Release Desktop QA]

After using mozregression tool I've determined that this is indeed a regression and I got the following pushlog after bisecting:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=76e8b769a7c00797dcaeef19cbaaa564f1f373b6&tochange=1c30a781b423462afdef09e088e5e601437b5bdc

Based on the pushlog looks like the culprit would be bug 1510569 but not entirely sure if this is right. Needinfo the assignee from bug 1510569 to take a look.

Comment 2

[Mike Conley (:mconley) (:⚙️) (PTO: May 24 - June 2nd)]

Hm... that changeset range shows a backout for bug 1510569, and then that patch definitely landed. I'd be pretty surprised if that caused the issue, but stranger things have happened.

Hey Bogdan, are you aware of any public Facebook pages with videos that I can use to reproduce this? I don't have a Facebook account to test with.

Comment 3

[Barret Rennie [:barret] (they/them)]

mconley: I can reproduce this for you if that helps.

Bogdan, I would be very surprised if the backout of that patch caused this.

Comment 4

[Mike Conley (:mconley) (:⚙️) (PTO: May 24 - June 2nd)]

So I don't think this is a regression - I think we always behaved this way.

From some debugging, it looks like Facebook has an event handler for when the window gets blurred, at which point it pauses the video. When opening the PiP player window, we first focus the player window (pausing the video), and then we clone the frames to the new <video>. I think there's a race where the player window isn't aware that the video has been paused, and so the player window continues to show the "pause" button. Clicking on the "pause" button causes us to attempt to pause an already playing video, which results in no user-discernible action.

There are, I think, a few things to do here:

1. When a video is being opened in Picture-in-Picture, we need the originating tab to continue to think it's focused and in the foreground (this is bug 1598654).
2. We need to make the Picture-in-Picture player window more resilient to the case where the video is paused soon after requesting that the PiP player window be opened, so that the "pause" toggle appears instead in the player window.

(1) is being taken care of in bug 1598654. Let's take care of (2) in this bug.

Comment 5

[Jens Stutte [:jstutte]]

:jaws, is there someone who can work on this? This bug is tracked as regression for FF74. Thank you!

Comment 6

[Pascal Chevrel:pascalc]

Untracking for 74 as this is not a regression and we have shipped several releases with this bug.

Comment 7

[(Away until May 24) Jared Wein [:jaws] (please needinfo? me)]

Hi Mike, were you planning on working on this from comment #4?

Comment 8

[Mike Conley (:mconley) (:⚙️) (PTO: May 24 - June 2nd)]

Eventually, yes - but it's likely to get much attention in the short term due to higher priority commitments.

Comment 10

[Mike Conley (:mconley) (:⚙️) (PTO: May 24 - June 2nd)]

I'm not going to have time to work on this in the short term, I'm afraid.

Comment 11

[Tim Spurway [:tspurway]]

S1 or S2 bugs need an assignee - could you find someone for this bug?

Comment 12

[(Away until May 24) Jared Wein [:jaws] (please needinfo? me)]

Mike would be the best person to work on this but he stated he doesn't have the time. I think we are just too resource-constrained at this point.