1722054 - Firefox hangs on embeded video/flash

Status: RESOLVED FIXED

(Core :: Graphics: WebRender, defect, P3)

Description

[saltire_hols]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:90.0) Gecko/20100101 Firefox/90.0

Steps to reproduce:

• Updated to 90.0.2 (64-Bit) on 2021-07-22
• Open any site with embeded flash or html5 or video (youtube, vimeo, bitsnpieces - younameit...) or many graphics - wait a sec or scroll to the first video.

Actual results:

• Firefox "crashes" - comes to a halt with errorwindow from WerFault.exe but NO crashreport or whatsoever inside firefox.
• Sometimes (mostly on embeded webm) the sound starts, but not the video and Firefox is unusable.
  PS - tried deactivating addons one-on-one by hand, doesn't change anything.

Expected results:

View site with graphics, videos etc without problems ... like it was untill 2021-07-21 using FF 90.0.1 (64-Bit).

Comment 1

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

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

Comment 2

[Jeff Muizelaar [:jrmuizel]]

Can you attach the graphics section of about:support?

Comment 3

[saltire_hols]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #2)

Can you attach the graphics section of about:support?

The whole bunch or only anything special?

Comment 4

[Jeff Muizelaar [:jrmuizel]]

The whole thing.

Comment 5

[saltire_hols]

Attachment: Graphics

Comment 6

[saltire_hols]

Attachment: graphics.txt

PS; What's wrong with bugzilla.mozilla.org ... choosing "preview" posts all & absolutely no chance for editing anything? This s_x ...

Comment 7

[Lee Salzman [:lsalzman]]

Attachment: Bug 1722054 - Restructure SwCompositeThread synchronization to not rely on job count. r?jrmuizel

This patch aims to address a worst-case theoretical possibility where the job count might for
some reason get out of sync, causing either the SwComposite thread or the main thread to deadlock
waiting on jobs that may never become available.

To this end, we get rid of the job count tracking entirely, and instead just track whether,
first, the SwComposite thread has completed all the jobs that have been queued for it, and,
second, that the main thread, having completed all jobs that were available, is waiting for
jobs to be available or completed such that the SwComposite thread would need to wake it up.
The main thread does not need to wait if it knows the SwComposite thread completed all jobs,
and the SwComposite thread does not need to signal if it knows the main thread is not waiting.

Otherwise stated, so long as both the main and SwComposite threads know there are no more
available jobs, then there is no way compositing can advance any further, and so compositing
must be finished. This avoids relying on having a job count that is always accurate to track
termination.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a880277ee90c
Restructure SwCompositeThread synchronization to not rely on job count. r=jrmuizel

Comment 9

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/a880277ee90c

Comment 11

[Ciprian Georgiu, Desktop QA]

I've tried to reproduce this issue by using the steps from comment 0, on an affected build, Firefox 90.0.2 (20210721174149) or on Nightly (2021-07-23). I did not encounter any crash on hangs on the websites mentioned in the report, using Win 10.

Hi saltire_hols! Could you please help us verify if this issue is fixed on latest Beta 92.0b?

Comment 12

[saltire_hols]

Hi there!

Sorry ... been off a time and had no chance to write here.
On my machine (with an update to ff 91 64bit "just this second") - I'm not any longer able to reproduce behavior willful!

So I think it was a hickup, fixed with another bug (on my machine at least) or else solved.
Following that I don't think I need to test out a beta, am I right?!

Cheers RH

Comment 14

[Darkspirit]

[Tracking Requested - why for this release]: Could this be worth an uplift? See bug 1739157.

Comment 15

[Ryan VanderMeulen [:RyanVM]]

What are your thoughts on this, Lee?

Comment 16

[Lee Salzman [:lsalzman]]

Comment on attachment 9234823 [details]
Bug 1722054 - Restructure SwCompositeThread synchronization to not rely on job count. r?jrmuizel

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Potential freezing and crashes with Software WebRender.
• User impact if declined: Potential freezing and crashes with Software WebRender.
• Fix Landed on Version:
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Patch has been in several releases without any issues.

Comment 17

[Daniel Bodea [:danibodea]]

I believe that in order for the Compositing in about:support to show "WebRender (Software)" it is necessary to have a video card that is not supported. 5 out of 5 systems I possess show WebRender displayed at Composition; if WebRender is disabled by pref (in an affected version), the "WebRender (Software)" is still not being shown, but "Direct3D 11". The issue could not be reproduced in several tries.

I will also attempt reproduction on Linux systems considering the Linux duplicate bugs.

Comment 18

[Daniel Bodea [:danibodea]]

(In reply to saltire_hols from comment #12)

Hi there!

Sorry ... been off a time and had no chance to write here.
On my machine (with an update to ff 91 64bit "just this second") - I'm not any longer able to reproduce behavior willful!

So I think it was a hickup, fixed with another bug (on my machine at least) or else solved.
Following that I don't think I need to test out a beta, am I right?!

Cheers RH

There's been a change in the code to fix your issue and should be verified that it does not break smth else, even if the issue no longer reproduces in the unfixed version.
Considering that we couldn't reproduce the original issue (explanation in the above comment), it would be best if you made sure that these browsers work as intended.

Could you, please, when you have some time, make sure it works properly?
Latest Beta: http://archive.mozilla.org/pub/firefox/releases/96.0b9/win64/en-US/Firefox%20Setup%2096.0b9.exe
Latest ESR: http://archive.mozilla.org/pub/firefox/releases/91.4.1esr/win64/en-US/Firefox%20Setup%2091.4.1esr.exe
Thanks!

Comment 19

[Daniel Bodea [:danibodea]]

One of my Ubuntu systems seems to show the WebRender (Software) at Composition in about:support, but the issue in this bug is not reproducing (hangs on html5 embedded videos/flash; youtube, vimeo, bitsandpieces), and neither could I reproduce the issues described in the duplicate bugs (random freeze after some use of the system or freeze when scrolling immediately after enabling PiP).

Could not find a system that shows WebRender (Software) at Composition (in Win10) in my team, either.
I believe this is one of those bugs that are really hard to repro.

If further info that might help me reproduce the issue is provided, please NI me.

Comment 20

[aoia7rz7l]

(In reply to Bodea Daniel [:danibodea] from comment #19)

Could not find a system that shows WebRender (Software) at Composition (in Win10)

Toggling about:preferences > General > Performance > Use recommended performance settings > Use hardware acceleration when available to off seems to work, at least on my end.

Comment 21

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9234823 [details]
Bug 1722054 - Restructure SwCompositeThread synchronization to not rely on job count. r?jrmuizel

Looks like this can fix some freezes/hangs. As noted, this has had quite a bit of bake time on release already, so the risk feels pretty low. Approved for 91.5esr.

Comment 22

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr91/rev/05a17e57d0fc

Comment 23

[Daniel Bodea [:danibodea]]

With the help from comment 20, I've succeeded in "activating" Composition = WebRender (Software) on every one of the Windows systems I have, but I could still not reproduce any kind of crash or failure. Unfortunately, this issue appears to be intermittent; a fact also supported by comment 12.

Could not be properly verified unless reproduced.
In any case, no new (and relevant) regressions were discovered in builds after the fix.