Closed Bug 1624944 Opened 4 months ago Closed 4 months ago

WebGL2RenderingContext.uniformMatrix4fv: Float32Array branch of (Float32Array or sequence) can't be a SharedArrayBuffer or an ArrayBufferView backed by a SharedArrayBuffer

Categories

(Core :: Canvas: WebGL, defect, P1)

76 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla76
Tracking Status
firefox-esr68 --- unaffected
firefox74 --- unaffected
firefox75 --- disabled
firefox76 --- verified

People

(Reporter: jujjyl, Assigned: jgilbert)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files)

It looks as if Firefox has lost its ability to call WebGL 2 entry points with SAB as an input(?):

STR:

  1. in about:config, enable dom.postMessage.sharedArrayBuffer.bypassCOOP_COEP.insecure.enabled=true
  2. Visit http://clb.confined.space/dump/unity/tiny3d-asmjs-tiny3d/Tiny3D.html

The page will fail with

TypeError: WebGL2RenderingContext.uniformMatrix4fv: Float32Array branch
of (Float32Array or sequence) can't be a SharedArrayBuffer or an
ArrayBufferView backed by a SharedArrayBuffer

Basically the code is calling

  glUniformMatrix4fv: function(location, count, transpose, value) {
      GLctx.uniformMatrix4fv(GL.uniforms[location], !!transpose, HEAPF32, value>>2, count*16);
  }

Observed in FF Nightly 76.0a1 (2020-03-24) (64-bit)

Using mozregression, I tracked it to bug 1615741. I'm afraid I'm not too knowledgable about SharedArrayBuffer, is it possible that you need to annotate your type with [AllowShared] as that bug indicates?

Flags: needinfo?(jujjyl)
Priority: -- → P3
Regressed by: 1615741

Ugh, how frustrating.

I guess we don't have tests for this.

Assignee: nobody → jgilbert
Severity: normal → critical
Flags: needinfo?(jujjyl)
Priority: P3 → P1
OS: macOS → All

The spec already has these annotations: https://www.khronos.org/registry/webgl/specs/latest/1.0/

Pushed by jgilbert@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e2fe93a06bf5
Uniform data uploads should accept SharedArrayBuffers. r=webidl,hsivonen
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla76

Comment on attachment 9136229 [details]
Bug 1624944 - Uniform data uploads should accept SharedArrayBuffers.

Beta/Release Uplift Approval Request

  • User impact if declined: Fix a regression where WebGL content (Unity?) might not run in Firefox.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: STR in bug
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This restores the behavior regressed by bug 1615741
  • String changes made/needed: none
Attachment #9136229 - Flags: approval-mozilla-beta?
Flags: qe-verify+
QA Whiteboard: [qa-triaged]

AIUI this is all disabled outside of nightly right now?

Attached image blank_page.gif

Hello! Reproduced the issue using Firefox 76.0a1 (20200325213906) on Windows 10x64.
The page is properly loaded using Firefox 76.0a1 (20200329214909) on Windows 10x64, macOS 10.12 and Ubuntu 18.04.

I noticed here that after opening the website on Windows 10x64 and Ubuntu 18.04 a blank page is displayed and the correct content is shown only after a browser interaction e.g clicking inside address Bar. Is this expected? Attached a screen recording.

Flags: needinfo?(jgilbert)
Flags: needinfo?(jgilbert) → needinfo?(jujjyl)

Comment on attachment 9136229 [details]
Bug 1624944 - Uniform data uploads should accept SharedArrayBuffers.

SAB are disabled, I don't believe we need this in 75.

Attachment #9136229 - Flags: approval-mozilla-beta? → approval-mozilla-beta-

Alexandru: interesting find! That is not expected. Not sure what is happening there. When I try this on macOS on FF Nightly or Chrome, the page does launch immediately. There should not be anything that'd block rendering like that, but it should immediately start drawing frames.

For curiosity, here is another version of the same demo: http://clb.confined.space/dump/unity/Wasm-Tiny3D/Tiny3D.html , but without SharedArrayBuffer. I wonder if that has the same behavior on your affected system?

Flags: needinfo?(jujjyl) → needinfo?(alexandru.trif)

Thanks for the quick fix Jeff! Confirmed FF Nightly runs smooth now.

See Also: → 1627594

(In reply to Jukka Jylänki from comment #13)

Alexandru: interesting find! That is not expected. Not sure what is happening there. When I try this on macOS on FF Nightly or Chrome, the page does launch immediately. There should not be anything that'd block rendering like that, but it should immediately start drawing frames.

Yes, you are right when doing this on macOS 10.12 it loads as expected. I filled bug 1627594 for this and closing this one as verified based on comment 11.

For curiosity, here is another version of the same demo: http://clb.confined.space/dump/unity/Wasm-Tiny3D/Tiny3D.html , but without SharedArrayBuffer. I wonder if that has the same behavior on your affected system?

The above page loads as expected on Firefox 76.0a1 (20200405212522) on Windows 10x64, Ubuntu 18.04 and macOS 10.12.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
Flags: needinfo?(alexandru.trif)
You need to log in before you can comment on or make changes to this bug.