User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0 Build ID: 20150224030228 Steps to reproduce: https://www.khronos.org/registry/webgl/sdk/tests/conformance/extensions/webgl-depth-texture.html?webglVersion=1 Actual results: conformance/extensions/webgl-depth-texture.html (69 of 72 passed) failed: gl.getParameter(gl.DEPTH_BITS) should be >= 16. Was 0 (of type number). failed: gl.getParameter(gl.DEPTH_BITS) should be >= 16. Was 0 (of type number). failed: gl.getParameter(gl.DEPTH_BITS) should be >= 24. Was 0 (of type number). Expected results: Chrome passes all the tests. Firefox fails the test with both the ANGLE and OpenGL backends.

This was observed to fail on the following devices: - GIADA, MACBOOK_AIR_OSX, MACBOOK_AIR_WIN, MACBOOK_PRO_OSX, MACBOOK_PRO_WIN, MACMINI, MACPRO, NEXUS-10, SAMSUNG-GT, SURFACE, WINDBOX, HASWELL, HPOMEN On SAMSUNG-GT, the test even crashed, see https://bugzilla.mozilla.org/show_bug.cgi?id=1178610 . The test was observed to pass on the following devices: - SPARK, NEXUS-4, NEXUS-5 See https://bugzilla.mozilla.org/show_bug.cgi?id=1178601 for hardware configuration details of these systems.

Reduced test case (needs to be put inside the extensions/ directory of the 1.0.3 test suite).

It seems that the depth attachment is not actually attached to the Framebuffer of WebGLFramebuffer, so when we query for the depth, we get 0 since the currently bound Framebuffer (the Framebuffer of WebGLFramebuffer) has no depth attachment. I was thinking that we should actually attach depth buffers to the Framebuffers, but it was probably a conscious decision not to do it in the first place, so I am not too sure about that idea. Any ideas Jeff?

I tried the test on MacOS and Win10 with lastest m-c. The test has passed.