1415575 - Firefox Developer Edition 58.0b1 renders black canvas on WebGL content

Status: RESOLVED INCOMPLETE

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

Description

[Jukka Jylänki]

STR:

Visit http://mzl.la/webassemblydemo in current latest Firefox Developer Edition 58.0b1 on Linux.

Observed: The canvas page renders black image instead of the scene content.

In Firefox Nightly 2017-11-08 this issue does not occur, so this looks like an intermittent failure that slipped on to Developer Edition? Also in Firefox Beta (Quantum) 57.0 channel the issue does not occur.

Tried to use mozregression to find which commit would have broken this and where the fix would be, but mozregression does not seem to work for bisecting Developer Edition, and stabbing random dates on Nightly, I'm unable to find the failure where it occurred on Nightly.

Marking this down under WebGL since it is WebGL content that has stopped displaying, but I don't know really if this is a WebGL failure.

Comment 1

[Jukka Jylänki]

In about:support, WebGL 1 and 2 contexts and their available extensions seem to be populated normally without issues. However there are these reports, which I'm not sure if they mean anything:

Decision Log
HW_COMPOSITING	
blocked by default: Acceleration blocked by platform
OPENGL_COMPOSITING	
unavailable by default: Hardware compositing is disabled
WEBRENDER	
opt-in by default: WebRender is an opt-in feature
unavailable by runtime: Build doesn't include WebRender
OMTP	
disabled by default: Disabled by default

Comment 2

[Jukka Jylänki]

Looks like other pages exhibit the black screen as well, e.g. at

http://www.geeks3d.com/webgl/

Comment 3

[Michael Leu[:Lenzak](UTC+8)]

Hi Jukka

I tested the 2 websites on Developer Edition but both of them show no problem.

I ran it on Ubuntu 16.04, core i3-3217U and HD4000 graphics.

What GPU did you run those tests on, perhaps it is related to hardware or driver?

Comment 4

[Daosheng Mu[:daoshengmu]]

It has already been fixed at Nightly.

d2580222abc7 Jeff Gilbert — Bug 1414977 - Skip DrawElements if !indexCount, not !lastVert. - r=daoshengmu
25856ffb9083 Jeff Gilbert — Bug 1414977 - Add test for drawing without index validation. - r=daoshengmu
c0a66ad2d873 Jeff Gilbert — Bug 1414977 - Allow webgl.force-index-validation:-1 to disable index validation for testing. - r=daoshengmu

Please wait for the next update. Sorry for the inconvenient.

Comment 5

[Jukka Jylänki]

(In reply to Michael Leu[:Lenzak](UTC+8) from comment #3)
> What GPU did you run those tests on, perhaps it is related to hardware or
> driver?

The GPU I was running on is an Asus GTX 1060.


(In reply to Daosheng Mu[:daoshengmu] from comment #4)
> It has already been fixed at Nightly.
> 
> d2580222abc7 Jeff Gilbert — Bug 1414977 - Skip DrawElements if !indexCount,
> not !lastVert. - r=daoshengmu
> 25856ffb9083 Jeff Gilbert — Bug 1414977 - Add test for drawing without index
> validation. - r=daoshengmu
> c0a66ad2d873 Jeff Gilbert — Bug 1414977 - Allow
> webgl.force-index-validation:-1 to disable index validation for testing. -
> r=daoshengmu
> 
> Please wait for the next update. Sorry for the inconvenient.

Thanks for digging up the cause. Do you know what is the next update in detail? Is there a possibility of this bug leaking over to stable?

I'm asking because I am not 100% clear on the release trains model that Firefox Developer Edition has. Reading https://hacks.mozilla.org/2017/04/simplifying-firefox-release-channels/ I understand that Firefox Developer Edition would now be the same as Beta but only with a different set of tools and themes? If so, does this mean that Firefox Beta 58 will have this bug when it ships, and Firefox Stable 58 will also have this bug when it ships, and to avoid that from happening, these fixes should be uplifted to Firefox 58 branch? Or is there a different model with the release branches that FF 58 Stable and FF 58 Beta will not have a danger of getting this bug in?

Comment 6

[Daosheng Mu[:daoshengmu]]

I am not quite sure either. I know it has been resolved at 58.0a1. We need a release engineer to give us some explanation.

Comment 7

[Jukka Jylänki]

(In reply to Daosheng Mu[:daoshengmu] from comment #6)
> I know it has been resolved at 58.0a1.

Version 58.0a1 is older than 58.0b1? I think the issue appeared first time only on 58.0b1.

Jeff, do you know if there's a chance that your fix will need to be uplifted to not slip out a bad release?

Comment 8

[Kelsey Gilbert [:jgilbert]]

(In reply to Jukka Jylänki from comment #7)
> (In reply to Daosheng Mu[:daoshengmu] from comment #6)
> > I know it has been resolved at 58.0a1.
> 
> Version 58.0a1 is older than 58.0b1? I think the issue appeared first time
> only on 58.0b1.
> 
> Jeff, do you know if there's a chance that your fix will need to be uplifted
> to not slip out a bad release?

We shouldn't need to do anything special, since we landed in 58.

Comment 9

[Kelsey Gilbert [:jgilbert]]

Ok, so it probably slipped into 58 between our early and late Nightly->Dev merges. It should be fixed when the late merge happens. I'll try to figure out when this is.

Comment 10

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

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 11

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

The severity field is not set for this bug.
:jgilbert, could you have a look please?

For more information, please visit BugBot documentation.