1123081 - Fx36: Permanent crashes when trying to play a YouTube video with OMTC disabled

Status: RESOLVED DUPLICATE of bug 1099074

(Core :: Audio/Video, defect)

Description

[Marat Tanalin]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150108202552

Steps to reproduce:

1. Disable OMTC (by setting the `layers.offmainthreadcomposition.enabled` pref to `false`). (This is a workaround for the bug 1067470 introduced in Firefox 33; the workaround did work well before Firefox 36.)

2. Try to play any video on YouTube.com.


Actual results:

Firefox 36 beta crashes almost always when trying to play any video on YouTube (in fact absolutely always — probably just some pre-video advertising clips sometimes play successfully, but not videos themselves).

Firefox 35 did not crash, the issue is introduced in version 36 (discovered the bug after auto-updating Fx 35 beta to Fx 36 beta).

The bug is maybe related to MSE enabled starting from Firefox 36 according to Firefox 36 Beta Notes (https://www.mozilla.org/en-US/firefox/36.0beta/releasenotes/ ):

"Implemented a subset of the Media Source Extensions (MSE) API to allow native HTML5 playback on YouTube".

With hardware acceleration disabled, YouTube does not crash Firefox 36, but then (even aside from performance consequences) Firefox-UI fonts are rendered somewhat blurry.


Expected results:

Firefox should play YouTube videos without crashing.

Comment 1

[:Gijs (he/him)]

Please provide crash report links from about:crashes.

Comment 2

[Marat Tanalin]

https://crash-stats.mozilla.com/report/index/533269af-c250-4444-8439-a4e0e2150119

Tested with a new clean profile.

By the way, maps.google.com causes Fx36 crashes for me too (like for reporter of the bug 1088833):

https://crash-stats.mozilla.com/report/index/0ac5c900-8f37-4ed3-9e94-62e602150119

Given links in "Related Bugs" section on these two crash pages, this bug 1123081 is probably formally a duplicate of bug 1088833 / bug 1122285, but I am encountering crashes on YouTube (which may be important) not mentioned at all in those bug reports.

Comment 3

[:Gijs (he/him)]

[Tracking Requested - why for this release]:
Crashes are sad, let's not have crashes.

Milan, I somewhat agree that youtube is different from maps, but I'm not sure if they're both doing the same thing leading to the crash or whatever... :-\
Thoughts?

Comment 4

[Milan Sreckovic [:milan] (needinfo for best results)]

I'm guessing this is the same as bug 1099074.

Could you attach the Graphics section from about:support?  In particular, I'm guessing it's showing "1/1 Direct3D 10" in the GPU Accelerated Windows and "direct2d 1.1" in AzureCanvasBackend?

If yes, if you change the gfx.canvas.azure.backends to "direct2d,skia,cairo" (i.e., remove the leading direct2d1.1 from the default), does the crash go away?

Comment 5

[Marat Tanalin]

(In reply to Milan Sreckovic [:milan] from comment #4)
> Could you attach the Graphics section from about:support?

Adapter Description: NVIDIA GeForce GTX 650 Ti BOOST
Adapter Drivers: nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um
Adapter RAM: 2048
Device ID: 0x11c2
Direct2D Enabled: true
DirectWrite Enabled: true (6.2.9200.16492)
Driver Date: 12-13-2014
Driver Version: 9.18.13.4709
GPU #2 Active: false
GPU Accelerated Windows: 1/1 Direct3D 10
Subsys ID: 356d1458
Vendor ID: 0x10de
WebGL Renderer: Google Inc. -- ANGLE (NVIDIA GeForce GTX 650 Ti BOOST Direct3D9Ex vs_3_0 ps_3_0)
windowLayerManagerRemote: false
AzureCanvasBackend: direct2d
AzureContentBackend: direct2d 1.1
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0

> In particular, I'm guessing it's showing "1/1 Direct3D 10" in the GPU
> Accelerated Windows and "direct2d 1.1" in AzureCanvasBackend?

Yes (see above).

> If yes, if you change the gfx.canvas.azure.backends to "direct2d,skia,cairo"
> (i.e., remove the leading direct2d1.1 from the default), does the crash go
> away?

Changing `gfx.canvas.azure.backends` to `direct2d,skia,cairo` helps with YouTube.com, but does not help with maps.google.com (Google Maps are still crashing always).

Comment 6

[Sylvestre Ledru [:Sylvestre]]

Sorry but I am not sure we care anymore of OMTC=off, at least, not enough to block 36.

Comment 7

[Marat Tanalin]

Then you should probably care about the bug 1067470.

Otherwise, starting from version 36, Firefox may start to die fast:

* with OMTC disabled it crashes (this bug),
* with OMTC enabled it has repainting issues when switching tabs (bug 1067470),
* with hardware acceleration disabled (a workaround for both bugs), UI fonts are blurred and performance is degraded.

Firefox market share is already below 15% and continues to fall. Such serious bugs in stable (!) versions can ruin Firefox at all.

It's probably time to extend release cycle (new versions are apparently released too often to provide enough high quality of end product) while making quality assurance MUCH stronger.

Comment 8

[Sylvestre Ledru [:Sylvestre]]

(In reply to Marat Tanalin | tanalin.com from comment #7)
> Then you should probably care about the bug 1067470.
We do care about this bug... It is tracked and many people in the gfx team tried to reproduce it... It is just hard to fix bugs we cannot reproduce...

Comment 9

[Marat Tanalin]

(In reply to Sylvestre Ledru [:sylvestre] from comment #8)

That's why Firefox development probably needs to slow down. Code is written and new versions are released too fast to be quality.

Comment 10

[Milan Sreckovic [:milan] (needinfo for best results)]

Since the fixes are different, I'd like this bug to be about the original issue - YouTube videos crash, as illustrated by the first crash report mentioned in comment 2.  This would make it a duplicate of bug 1099074, which is in process of getting approved for the beta.

The maps crash should be a separate bug, and it sounds like it is a duplicate of bug 1088833.

Comment 11

[Milan Sreckovic [:milan] (needinfo for best results)]

(In reply to Marat Tanalin | tanalin.com from comment #9)
> (In reply to Sylvestre Ledru [:sylvestre] from comment #8)
> 
> That's why Firefox development probably needs to slow down. Code is written
> and new versions are released too fast to be quality.

We appreciate all the help you're giving us though.  The "hard to reproduce" is because of the kind of hardware/driver combination we have, but we're actually expanding our testing to third parties that have a wider range of hardware than what we could practically host in house.  Even as that starts, the community members like you, not only finding problems, but actually helping us in detail is amazingly helpful and certainly appreciated.