1654277 - [MacOS] Unexpected behaviour scrolling facebook.com/watch videos

Status: VERIFIED FIXED

(Core :: Audio/Video: Playback, defect)

Description

[Marcela (Please NI request to Brindusa Tot)]

Affected versions:
Nightly 80.0a1 (2020-07-21)

Affected platforms:
Platform: macOS (MacBook Pro touch bar)

Steps to reproduce:

1. Launch the Firefox browser and reach https://www.facebook.com/watch
2. Unmute the first video and start to play
3. Hit the Media Control button from the touch bar in order to pause/play the video.
4. Scroll down, reach another video, and hit the media control button (pause/play) many times.

Expected result:
The user should be able to pause and start the video without any issues.

Actual result:
The video start tho play with cut noises at the beginning and in an unexpected way it scrolls up

Comment 1

[Alastor Wu [:alwu]]

TL;DR, I'll mail to Facebook to see if they're using MediaSession API on Chrome only.

---

The video start tho play with cut noises at the beginning
That is because we're trying to resume multiple videos at the same time. If you changes your viewport to allow you to see two videos at the same time, then you would notice that, when pressing play, both video would be resumed, but one of them would be paused by Facebook immediately because of their website script logic, which is to pause video when video is out of the viewport.

Our implementation is to control all media in the same page, so it's an expected behavior. But Facebook has its own logic not to show a specific video so they pause it explicitly. The interesting thing is that, when I test this on Chrome, they would only resume one media when pressing play.

The first possibility I think of is that Facebook only enable MediaSession API on Chrome, so they can allow to script to decide which video should be paused, then they can perfectly control the media behavior.

However, I can't clearly verify if they're using MediaSession API or not from their JS code, but if it's true, then we should ask them to use MediaSession API on Firefox. Then, this problem could be solved.

In addition, on Chrome I test a page which contains multiple playing media, then I observed that sometime I can control them together, sometime I can't. They seems having a special logic to determine with what media is abled to be controlled.

Comment 2

[Alastor Wu [:alwu]]

However, on MacOS 10.14.6, I didn't encounter "scrolling up" issue, could you make a screenrecording for me?
Thank you.

Comment 3

[Alastor Wu [:alwu]]

I can't reproduce "scrolling up" issue on Window10 as well.

Comment 4

[Marcela (Please NI request to Brindusa Tot)]

Attachment: FacebookWatch_FF_sound_scrollup.mp4

Comment 5

[Marcela (Please NI request to Brindusa Tot)]

(In reply to Alastor Wu [:alwu] from comment #2)

However, on MacOS 10.14.6, I didn't encounter "scrolling up" issue, could you make a screenrecording for me?
Thank you.

This behavior is aleatory and difficult to reproduce it. I uploaded a file with the evidence. You can see when display suddenly scrolls up from 00:22. Also, you can notice sound problems as well the fact that video some times mute when I hit media control play.
Let me know if you need anything else.

Comment 6

[Alastor Wu [:alwu]]

From the screen-recording video, I noticed that the screen seems already scrolling up before you were clicking on the media control key?

So you mean this behavior is intermittent? Are you able to reproduce it on a clean profile or a private window?

It seems to me that that is probably a Facebook issue because the media control doesn't have an ability to move the page up/down. In addition, I'm also wondering if it's related with the regions, maybe this issue only happen on certain region (version) Facebook website, because I still can't reproduce that on my MacOS and Windows10. For example, one possibility is that, because pressing media key would also control the video, which is not in the viewport and is in the above, and some version of Facebook mighg focus the viewoport to the controlled media immediately, which cause a scrolling up.

Anyway, I've reported this issue to Facebook to see if they can reply us.

Comment 7

[Marcela (Please NI request to Brindusa Tot)]

Attachment: ScrollSound_CleanProfile.mp4

Comment 8

[Marcela (Please NI request to Brindusa Tot)]

(In reply to Alastor Wu [:alwu] from comment #6)

From the screen-recording video, I noticed that the screen seems already scrolling up before you were clicking on the media control key?

No, it happens after clicking on Play

So you mean this behavior is intermittent? Are you able to reproduce it on a clean profile or a private window?

Yes, I was able to reproduce it with a clean profile
I'll attach a file where:

• you will see how the screen scrolling up after I click on the media control key
• you will ear a choppy sound every time that I press Play on the media control key
• you will see how the video try to resume showing a blue spin
• you will see how the video is muted after press play/pause key

It seems to me that that is probably a Facebook issue because the media control doesn't have an ability to move the page up/down. In addition, I'm also wondering if it's related with the regions, maybe this issue only happen on certain region (version) Facebook website, because I still can't reproduce that on my MacOS and Windows10. For example, one possibility is that, because pressing media key would also control the video, which is not in the viewport and is in the above, and some version of Facebook mighg focus the viewoport to the controlled media immediately, which cause a scrolling up.

Anyway, I've reported this issue to Facebook to see if they can reply us.

After all, could be a Facebook problem.

Comment 9

[Marcela (Please NI request to Brindusa Tot)]

Let me know if you need anything else.

Comment 10

[Alastor Wu [:alwu]]

Thank you so much. I've talked to Facebook folks, I will fix this issue on our side, changing our behavior to not to control all media on the page to prevent from this issue.

Comment 11

[Alastor Wu [:alwu]]

In addition, FB mentioned that they have multiple version of "Watch", so I guess that is why I can't reproduce the scrolling up issue.

Comment 12

[Alastor Wu [:alwu]]

Hi, Marcela,
Could you help me try this build [1] to see if the issue gets fixed?
Thank you.
[1] https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/ddeShV66TdqlEHY8hGKBuA/runs/0/artifacts/public/build/target.dmg

Comment 13

[Marcela (Please NI request to Brindusa Tot)]

Attachment: newbuild.mp4

Comment 14

[Marcela (Please NI request to Brindusa Tot)]

Hi Alastor!
Apparently using the build proposed by you [1], this issue does not happen anymore. Sound is ok and scrolling up doesn't happen. I'll attach a file with evidence.
[1] https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/ddeShV66TdqlEHY8hGKBuA/runs/0/artifacts/public/build/target.dmg

Comment 15

[Alastor Wu [:alwu]]

Attachment: Bug 1654277 - part1 : prevent doing play/pause if the controller is already playing/paused.

Comment 16

[Alastor Wu [:alwu]]

Attachment: Bug 1654277 - part2 : stop controlling those media which are not the one that users is intending to control.

Comment 17

[Alastor Wu [:alwu]]

Attachment: Bug 1654277 - part3 : add a test for only resuming latest paused media.

Comment 18

[Alastor Wu [:alwu]]

Attachment: Bug 1654277 - part1 : add assertion to ensure we don't get unsupported key for default handler.

Comment 19

[Alastor Wu [:alwu]]

Attachment: Bug 1654277 - part2 : pause playing media but stop already paused media when receiving 'pause'.

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/53cefb9efce4
part1 : add assertion to ensure we don't get unsupported key for default handler. r=chunmin
https://hg.mozilla.org/integration/autoland/rev/f901c6481cf0
part2 : pause playing media but stop already paused media when receiving 'pause'. r=chunmin
https://hg.mozilla.org/integration/autoland/rev/491b6b3d363d
part3 : add a test for only resuming latest paused media. r=chunmin

Comment 21

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/53cefb9efce4
https://hg.mozilla.org/mozilla-central/rev/f901c6481cf0
https://hg.mozilla.org/mozilla-central/rev/491b6b3d363d

Comment 22

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:alwu, 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.

Comment 23

[Marcela (Please NI request to Brindusa Tot)]

I can confirm this issue is fixed, I verified using Nightly 81.0a1 on MacOS 10.14. I'll change flags accordingly.