Closed Bug 1703217 Opened 3 years ago Closed 1 year ago

With Autoplay "Block Audio and Video", a throbber is sometimes shown on the c.leprogres.fr website, taking CPU time, and the video cannot be played.

Categories

(Web Compatibility :: Site Reports, defect, P3)

Product:
Web Compatibility
Component:
Site Reports
Version:
Firefox 87
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: vincent-moz, Unassigned)

References

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0

Steps to reproduce:

  1. In the Autoplay settings, block audio and video.
  2. Open some page from the c.leprogres.fr website, e.g. https://c.leprogres.fr/insolite/2021/04/05/d-bayard-voici-l-ancetre-de-la-liseuse-electronique-en-1-815 (may need subscription).

Actual results:

A frame with a video is shown. The video is not played, but a throbber appears over it, which takes about 30% CPU time on my machine (even when the Firefox window is not visible). Moreover, the video cannot be played. This is not always reproducible.

Expected results:

Instead of a throbber, one should get the video with a Play button.

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core

I created a free account, but I'm not able to reproduce this without a paid account. Is there any chance you can reach out to the site and ask them to provide us with access to investigate? Or provide a link that doesn't require a paid account to view.

Flags: needinfo?(vincent-moz)

Also, what's the behavior for you if autoplay is not disabled?

Anyway I could reproduce the issue on https://www.20minutes.fr/bordeaux/3016923-20210408-bordeaux-episode-gel-vient-aneantir-partie-significative-travail-vignerons-recolte (which doesn't require a subscription). But most of the time, this is fine.

If autoplay is not disabled, the video is played automatically.

Flags: needinfo?(vincent-moz)

Hmmm, I tried a couple times but wasn't able to reproduce the behavior on macOS. I'll see if we can reproduce on linux. What distro/version are you running, and did you install Firefox directly or from a package manager? Finally, can you reproduce this if you start Firefox in safe mode? What about with a new profile?

Flags: needinfo?(vincent-moz)
Flags: needinfo?(alwu)

Additional information: I left the 20minutes article in a tab while the video was blocked (as expected). But a few hours later, when I selected this tab, the video had the throbber. This occurred twice.

I'm using Debian/unstable with Debian's firefox 87.0-2 package.

I've tried Firefox with a new profile. I couldn't reproduce the problem yet, but the page takes much more time to completely reload with Ctrl-Shift-R: 8 seconds or more, vs 2 seconds.

Flags: needinfo?(vincent-moz)

To review:

  1. Sometimes the video is not played, but a throbber appears over it, which takes about 30% CPU time
  2. With a new profile, you haven't been able to reproduce (1), but a reload with Ctrl-Shift-R consistently takes 4x or more longer than Ctrl-Shift-R with your original profile

Can you use the performance profiler to record a traces when you're seeing (1) and (2)? See https://profiler.firefox.com/

Flags: needinfo?(vincent-moz)

I had let the Firefox with a new profile running with the 20minutes tab in background. And a half an hour ago, it started to take 50% - 100% CPU time instead of remaining idle. I clicked on the 20minutes tab... and saw the throbber over the video!

I'll see what I can do with the performance profiler.

Here's the trace with the new Firefox profile: https://share.firefox.dev/3fXgcRe

In both cases, I started the record, then typed Ctrl-Shift-R to reload, and once done, I captured the trace.

Flags: needinfo?(vincent-moz)

one should get the video with a Play button.
Hi, for c.leprogres.fr, I don't have a paid account, so I also could not be able to reproduce that. But for the play button part, that is mostly controlled by websites, because the control interface is customed JS code, not our default video control interface.

(In reply to Vincent Lefevre from comment #4)

Anyway I could reproduce the issue on https://www.20minutes.fr/bordeaux/3016923-20210408-bordeaux-episode-gel-vient-aneantir-partie-significative-travail-vignerons-recolte (which doesn't require a subscription). But most of the time, this is fine.
Not sure here what the issue was you mentioned, the video can't be played or the CPU is in the high load?

Would you mind to profile Firefox again with "Media" preset? From the results you profiled, I didn't see any suspicious media related thing. And also, what is the most important issue we would like to discuss here? CPU load? (c.leprogres.fr is not open for the normal users, and if the issue is related with control interface, then it's most likely a website's issue)

Thank you.

Flags: needinfo?(alwu) → needinfo?(vincent-moz)

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

Hi, for c.leprogres.fr, I don't have a paid account, so I also could not be able to reproduce that. But for the play button part, that is mostly controlled by websites, because the control interface is customed JS code, not our default video control interface.

The 20minutes issue seems very similar. So perhaps you should focus on it.

(In reply to Vincent Lefevre from comment #4)

Anyway I could reproduce the issue on https://www.20minutes.fr/bordeaux/3016923-20210408-bordeaux-episode-gel-vient-aneantir-partie-significative-travail-vignerons-recolte (which doesn't require a subscription). But most of the time, this is fine.
Not sure here what the issue was you mentioned, the video can't be played or the CPU is in the high load?

The issue: A throbber appears instead of the play button. I think that the high CPU load is a consequence. Actually, I've just noticed that I can play the video, but I need to click somewhere on the video except over the throbber.

Would you mind to profile Firefox again with "Media" preset? From the results you profiled, I didn't see any suspicious media related thing.

With the Firefox started using the new profile, I did a Ctrl-Shift-R on the 20minutes article, and the video appeared with the throbber. I did a capture while this throbber was active: https://share.firefox.dev/3skcXWy

When the tab with this article is the foreground tab, Firefox takes about 110% CPU time (according to htop), whether the Firefox window is visible or not.

However, I've noticed a high CPU load even when the video has a play button (but this case may be specific to the new profile and may be unrelated to the video). Here's the corresponding capture: https://share.firefox.dev/3wTDeOX

If you need a capture of something else, e.g. while loading the page, please tell me exactly what you need.

And also, what is the most important issue we would like to discuss here? CPU load?

The issue to solve: avoid the throbber. This should also solve the problem with the high CPU load with my usual Firefox profile.

Flags: needinfo?(vincent-moz)
Severity: -- → S3
Priority: -- → P3

From both profile you captured in comment12, I don't think the problem was in the media part, because in both result, media didn't run anything on the background after autoplay got blocked. We encoutered a situation where media element kept sending a lot of DOM event that causes the main thread super busy that results in a high CPU load (bug 1686696). But in those two profiles, media element only dispatched very few events. Only 5 collected samples related with event dispatching (searching HTMLMediaElement::Dispatch in Call tree) in the first result, and zero in the second result.

By checking the Call Tree, I found that around 31% time were spending on Graphic and 19% on Javascript in the first result, and 21% on Graphic and 23% on Javascript in the second result. I suspect the issue would probably be more related with them. Throbber is related with the video controller the website uses, so it might be possible that they got an issue in their code and run something in JS repeatedly which causes using CPU a lot. I'm not sure how Graphic could impact here, so I will NI some graphic folk to see if they have any insight.

In addition, on both results I also noticed that there were A LOT of readystatechange events got dispatched (go to Marker Table and filtering keyword by typing readystatechange) That also looks suspicous.

Add this bug to gfx-triage to see if they have any ideas about this issue (See comment13)

Blocks: gfx-triage

Hi, Smaug,
Would you mind to help me check this issue as well? The bug reporter said the CPU usage was really high while he was browsing a certain website, and I noticed that there were A LOT of readystatechange events got dispatched (see comment13), so I wonder if that could be related with the CPU issue.
Thank you.

Flags: needinfo?(bugs)

(In general the website seems to take lots of cpu time in all the browsers I tried, and FF was taking actually less than some others)

The second profile in comment 13 has lots_of XMLHttpRequest usage. And XHR does trigger certain number of readystatechange events per request, but those all look fine. It is just that that the website triggers so many XHRs.

The most surprising part of the profile is InternalStorageAllowedCheck. Filing a bug about that.

Flags: needinfo?(bugs)

It looks like we're rebuilding display lists every frame for the thobber, which takes a fair amount of time.

I wasn't able to reproduce that state though (always switches to a static play button), so not sure what the site is doing to implement their throbber.

We don't think this is graphics related, likely a website bug in their handling of blocked content.

No longer blocks: gfx-triage
Component: Audio/Video: Playback → Desktop
Product: Core → Web Compatibility

Needs Triage.

Flags: needinfo?(raul.bucata)
Flags: needinfo?(oana.arbuzov)

I could not reproduce the issue on my side with https://www.20minutes.fr/bordeaux/3016923-20210408-bordeaux-episode-gel-vient-aneantir-partie-significative-travail-vignerons-recolte and https://c.leprogres.fr/insolite/2021/04/05/d-bayard-voici-l-ancetre-de-la-liseuse-electronique-en-1-815 requires a paid account.

Tested with:
Browser / Version: Firefox Nightly 92.0a1 (2021-07-27)
Operating System: Ubuntu 20.04.2

Vincent Lefevre does the issue still occur on your side?

Flags: needinfo?(vincent-moz)
Flags: needinfo?(raul.bucata)
Flags: needinfo?(oana.arbuzov)

With media.autoplay.default set to 5, the issue on https://c.leprogres.fr/insolite/2021/04/05/d-bayard-voici-l-ancetre-de-la-liseuse-electronique-en-1-815 still occurs with Firefox 88.0.1 (currently the latest version in Debian, due to dependency issues until the next stable is released).

Flags: needinfo?(vincent-moz)

I managed to see the throbber a few times on https://www.20minutes.fr/bordeaux/3016923-20210408-bordeaux-episode-gel-vient-aneantir-partie-significative-travail-vignerons-recolte, but the CPU usage was low.

Tested with:
Browser / Version: Firefox Nightly 98.0a1 (2022-01-26), Firefox Release 96.0.2
Operating System: Ubuntu 20.04.2

Vincent could you try again for https://www.20minutes.fr? Does it still reproduce on latest Firefox version with clean profile?

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(vincent-moz)

I can't reproduce the throbber with FF 98 and a clean profile and with media.autoplay.default set to 5 and autoplay set to block both audio and video. But https://www.20minutes.fr/bordeaux/3016923-20210408-bordeaux-episode-gel-vient-aneantir-partie-significative-travail-vignerons-recolte takes a lot of CPU time.

Flags: needinfo?(vincent-moz)

Vincent if you constantly reproduce it, could you record a fresh performance profile with the latest Firefox Nightly?

Flags: needinfo?(vincent-moz)

I was not able to reproduce this issue on the latest Nightly.

Tested on:
Operating system: Ubuntu 22.04 LTS
Firefox version: Nightly 111.0a1 (2023-02-02)

Closing this as worksforme. Feel free to reopen and leave a comment with more details if the issue reoccurs.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WORKSFORME

I'm not sure about this bug, but there has been a more general bug about not-being-played videos and high CPU time since at least FF 95 (according to Karl Tomlinson), though I reported it against FF 105: bug 1793310. This one still occurs with FF 109.

Flags: needinfo?(vincent-moz)
You need to log in before you can comment on or make changes to this bug.