1442186 - play() Promise stays pending forever when I open a new tab

Status: RESOLVED WORKSFORME

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

Description

[auk.david]

Attachment: "Can Autoplay" detection snippet (HTML+Javascript)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36

Steps to reproduce:

Hi there,

I'm working on a "can autoplay detection" feature based on https://github.com/video-dev/can-autoplay.
The idea is to use a fake stream (base64), play() it, and analyse the Promise returned to know if we can or can't autoplay.
The code snippet is in the attachment.

It works well in Chrome, Safari and Firefox, except for this specific case:
- I set "media.autoplay.enabled" to "false" in "about:config"
- I open a brand new tab on Firefox Quantum 58.0.2
- I copy/paste the URL targeting my static HTML file (see attachment)

Thanks for the help!


Actual results:

The autoplay never resolves/rejects (this behaviour is caught by a timeout set to 20s. I have increased it to 200s and it times-out too)


Expected results:

I expect the play() Promise to reject with a "NotAllowedError"

Comment 1

[roxleitan]

Managed to reproduce this issue on Mac OS X 10.12 and Windows 10 x64 using the latest Nightly 60.0a1(2018-03-06) with the STR from the description.

Comment 2

[Ralph Giles (:rillian)]

Chris, this looks related to the Block Autoplay changes?

Comment 3

[Chris Pearce [:cpearce (Not reading bugmail)]]

Firefox currently delays starting playback of audible media until the tab the media element is in has been focused. This stops tabs opened in the background (CTRL+Click on a link for example) from making noise unexpectedly. So you're hitting that.

If the promise returned by HTMLMediaElement.play() is not rejected inside of your time out, it is not safe to assume that autoplay is or isn't blocked. To be accurate, you should wait for the promise to be resolved.

Unfortunately our logic to delay playback is *before* the logic to check to see whether we should block the playback. We can move the delay-playback logic to after the logic to check whether we should reject the promise due to being blocked. Then you can assume that it's likely playback will not be blocked if the promise isn't rejected within your timeout.

Why don't you get rid of the timeout? Then your scripts would work as expected once the tab was focused...

Comment 4

[Chris Pearce [:cpearce (Not reading bugmail)]]

I realized I wasn't following the STR from comment 0 properly, but when I do, I cannot repro the timeout, which I think is an artifact of the unfortunate way we do the delaying playback start.

Comment 5

[auk.david]

Attachment: FF-autoplay.mov

Hi Chris,

Thx for your investigation.
In my full integration, the timeout helps me to fall back to an "autoplay not allowed" scenario (the media with a play button).
For the end-user, it's almost transparent and he can click on the play button to launch the media.

As you said, it's not about a "tab focus" issue due to "Ctrl + Click". I have added in attachment a video showing the exact reproducible case. The URL used in the snippet in this new attachment is https://bug1442186.bmoattachments.org/attachment.cgi?id=8955074.

I noticed something that can give you a hint:
- If I follow the same STR in "private navigation mode", the Promise always rejects with a "NotAllowedError" in less than 5ms.

Comment 6

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to auk.david from comment #5)
> In my full integration, the timeout helps me to fall back to an "autoplay
> not allowed" scenario (the media with a play button).
> For the end-user, it's almost transparent and he can click on the play
> button to launch the media.

So, why not just try to play the actual video, and if it doesn't play, show a play button to the user? What are you trying to achieve by testing in advance whether autoplay is blocked? Wouldn't the end result be the same to the user if you just handled the play() promise being rejected when the actual video has play() called?

Comment 7

[auk.david]

I'm working at Dailymotion for the Video Player, and it's a performance issue.
Your comment was our 1st iteration to handle the "autoplay policy" and after analysis, we discover the user experience was badly impacted.
Resolving the "can-autoplay" early helps us reduce HTTPs requests (Ads, video fragments) which consume our end-user bandwidths.

Comment 8

[Chris Pearce [:cpearce (Not reading bugmail)]]

OK. Thanks for clarifying that. Ignoring the issue of our play() promise timing out, have you considered just playing the video muted, and displaying a prominent unmute button? I've seen a few other big sites do this, was wondering of your thoughts on that user experience.

I've been unable to reproduce this in Firefox 58 and 60 on Mac, Linux, and Windows 10 unfortunately. I'll need to do more investigation... Maybe my machines have too many cores or somesuch to repro the timing required.

Also, we're still finalizing our UX for our block-autoplay behaviour, but you can test our current leading contender in Nightly behind if you set the prefs media.autoplay.enabled.user-gestures-needed=true and media.autoplay.enabled=false.

Comment 9

[auk.david]

We have considered this solution but it was rejected by a product decision.

Thanks for pointing the hardware issue. Here's my config if it can help:
- macOS Sierra
- version 10.12.6
- MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports)
- Processor 2,9 GHz Intel Core i5
- Memory 8 GB 2133 MHz LPDDR3
- Graphics Intel Iris Graphics 550 1536 MB

If you require more information, feel free to ask for help!

Comment 10

[Chris Pearce [:cpearce (Not reading bugmail)]]

I haven't had chance to look into this further yet, sorry, but I wanted to mention that I filed an issue against the Permissions API spec [1] to see if we can get a non-hacky way for web authors to detect whether autoplay of audible media is allowed.

[1] https://github.com/w3c/permissions/issues/172

Comment 11

[auk.david]

Hi Chris,

I have updated my Firefox to 59.0.2 and I can't reproduce this issue anymore.
Have you fixed something recently?

Thanks!

Comment 12

[Chris Pearce [:cpearce (Not reading bugmail)]]

I don't see anything in the changes that went into 59.0.2 that should affect the behaviour here... Maybe something else changed? It's possible that the timing of the build changed due to profile guided optimimzations in the compilation being different. Hard to prove that though.

Comment 13

[auk.david]

Hi Chris,

We were unable to reproduce this issue on our side and decided to close the issue in our bug tracker.

Thanks again for your investigation!

Comment 14

[Alastor Wu [:alwu]]

According to the comment12, close this bug.

Comment 15

[Minimarket Rak]

Thanks for many information https://www.minimarketrak.com/