1785041 - Visiting https://store.google.com/product/pixel_6a with autoplay blocked leads to massive jank/OOM

Status: RESOLVED WORKSFORME

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

Description

[Julian Descottes [:jdescottes]]

STRs (might crash your browser):

• check that autoplay is either on "block audio" or "block audio and video"
• open https://store.google.com/product/pixel_6a
• wait for the page to load

The page will initially open but remain in a loading state with a lot of blank areas. It seems the page is spamming the autoplay, which leads to huge memory consumption. Eventually depending on your hardware, the page will either load or the browser will stop.

Profile of a few seconds of this: https://share.firefox.dev/3AmHcn6

Emilio on Elements mentioned:

There seems to be multiple things to fix there, probably. Tons of time in the child just logging to the console for example, but also probably we should dispatch the GloballyAutoplayBlocked event once per document, or at least check that the permission is not already blocked here before dispatching the event: https://share.firefox.dev/3JWf25o

Comment 1

[Emilio Cobos Álvarez (:emilio)]

ni? Just to take a closer look at profiles when time allows, please don't hesitate from taking this or what not :)

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1785041 - Don't spam the console and front-end with autoplay blocked events. r=alwu

Once per video should be enough.

Comment 3

[Phabricator Automation]

Comment on attachment 9290114 [details]
Bug 1785041 - Don't spam the console and front-end with autoplay blocked events. r=alwu

Revision D154798 was moved to bug 1785089. Setting attachment 9290114 [details] to obsolete.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

So, the two dependent bugs improve stuff significantly, but the page is still calling play() on a loop... That's more of a web compat issue, I guess... But I guess there's also the issue that for default-autoplay-policy (which is to allow auto-play without audio) we don't allow this video to autoplay.

Digging a bit more into it, it seems that is because it has a single audio track, but with zero duration. It seems to me that should be allowed by the autoplay policy. I'll file a separate bug for that.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1785041 - Require positive duration for audio tracks to consider them for autoplay blocking as audible. r=alwu

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Ah, so comment 5 is enough to fix one of the <video> elements on the page but not the other, because we don't download metadata at all for this video, if I'm understanding correctly... Alastor, can you take a look? Should we just ask the google folks to fix their code?

Comment 7

[Alastor Wu [:alwu]]

This issue seems a web compat issue to me. Here is what happened.

In that page, the site created multiple media elements and tried to play them before loading their metadata. However, Firefox prohibits a site to autoplay a media without loading its metadata because we can't know whether the media is really audible or not. Among those elements which kept calling play() again and again (...and again many many times), only one element had a video resource. After loading the resource, we know that video is inaudible, so it would be allowed to play if our blocking autoplay setting is block audio.

I am not sure if I understand D154803 because I didn't see the situation you described. After loading the metadata, we regard that video as an inaudible video. Then it can start playing correctly if we open it under the default policy block audio.

The problem is that the website kept trying to play media before loading any media, which seems blocking loading other resources for the website. Note that, I will implement a new autoplay detection API in bug 1773551, and hope it could reduce these kind of similar issues in the future because we would provide website more information about whether they could play the media.

Back to this issue, however, I think we already provide enough indication for them (not allow autoplay) by rejecting those play promises. They should be responsible to handle those rejected error, and not block loading other resources. Yes, we should told them to fix the site.

Comment 8

[Alastor Wu [:alwu]]

Emilio, do you know where the best place is to report this bug to them? Thanks.

Comment 9

[Alastor Wu [:alwu]]

But those similar issues happen many times so far, which make me consider if we should implement something hacky to completely stop responsing to the play promise or made the element inaudible, if there are huge amount of requests for playing.

Comment 10

[Julian Descottes [:jdescottes]]

I think google might have fixed their website, at least I can't reproduce anymore today. It would still be great if we could avoid this issue as it seems to only affect Firefox.

Comment 11

[Emilio Cobos Álvarez (:emilio)]

We have a mozilla-google-discuss mailing list for this stuff, but yeah I can't repro this anymore either. The blocking bugs are still worth it tho.

Comment 12

[az [:az]]

Bug 1784738 may be related as well, though the reporter reported that the issue occurs with or without autoplay enabled. From my side, enabling autoplay fixed the problem and I was able to repro the reporter's issue when I disabled autoplay. Just wanted to provide another data point that may be helpful.

Comment 14

[Emilio Cobos Álvarez (:emilio)]

I think we can possibly close this as wfm. Google fixed this on their side and the patches landed should prevent the terrible behavior on the parent process.

Comment 15

[Julian Descottes [:jdescottes]]

Sounds good to me, thanks for all the work on the improvements Emilio!