Bug 250307

Summary: "TypeError: Type error" when calling WebGL bufferData with typed array backed by growable SharedArrayBuffer
Product: WebKit Reporter: Ian Kettlewell <Ian.kettlewell>
Component: WebGLAssignee: Yusuke Suzuki <ysuzuki>
Status: RESOLVED DUPLICATE    
Severity: Normal CC: dino, kbr, kkinnunen, webkit-bug-importer, ysuzuki
Priority: P2 Keywords: InRadar
Version: Safari Technology Preview   
Hardware: Mac (Apple Silicon)   
OS: macOS 13   
See Also: https://bugs.webkit.org/show_bug.cgi?id=248024
Bug Depends on: 248024    
Bug Blocks:    
Attachments:
Description Flags
Index.html file with the code to reproduce the issue
none
server to run the file with none

Description Ian Kettlewell 2023-01-08 21:01:07 PST 
Created attachment 464415 [details]
Index.html file with the code to reproduce the issue

As title says. The following code errors in Safari Technical Preview 160:

```
 let gl =
            canvas.getContext('webgl2');


        const sab = new SharedArrayBuffer(1024, {
            maxByteLength: 2048 // This is important, without it the page runs fine
        });

        const data = new Uint8Array(sab, 0, 32);
        let buffer = gl.createBuffer();
        gl.bindBuffer(gl.ARRAY_BUFFER, buffer); // TypeError: Type error
        gl.bufferData(gl.ARRAY_BUFFER, data, gl.STATIC_DRAW);
```

I discovered this in a game jam entry I made (https://ianjk.com/ld52/) that I was testing in the Safari Technology Preview. For some reason the SharedArrayBuffer backing the WebAssembly binary is automatically made 'growable' in Safari Technology Preview 160. In Safari 16.2 that does not happen so both the attached example and my game jam entry run fine.

I'm not versed in where to file WebKit bugs so I've filed this under 'WebGL', but please reclassify if there's a more appropriate 'Component'. :)
Comment 1 Kimmo Kinnunen 2023-01-09 01:43:46 PST 
Created attachment 464416 [details]
server to run the file with
Comment 2 Kimmo Kinnunen 2023-01-09 01:45:23 PST 
Likely regressed with bug 248024

Yusuke, it appears intentional.
Is there anything WebGL code can do to opt into using the growable array buffers?
Comment 3 Radar WebKit Bug Importer 2023-01-09 01:45:34 PST 
<rdar://problem/104022514>
Comment 4 Yusuke Suzuki 2023-01-09 06:00:18 PST 
(In reply to Kimmo Kinnunen from comment #2)
> Likely regressed with bug 248024
> 
> Yusuke, it appears intentional.
> Is there anything WebGL code can do to opt into using the growable array
> buffers?

Growable SharedArrayBuffer / Resizable ArrayBuffer cannot be used for IDL saying ArrayBuffer without [[AllowResizable]] annotation. (This is explicitly specified for resizable array-buffer / growable shared-array-buffer).

https://webidl.spec.whatwg.org/#AllowResizable

"If the [AllowResizable] extended attribute and the [AllowShared] extended attribute both appear on one of the buffer source types, it creates a new IDL type that allows the buffer source type to be additionally backed by an ECMAScript SharedArrayBuffer that is growable."

Thus, given that WebGL IDL is not saying [[AllowResizable]], I think this behavior is expected. (bufferData does not have [[AllowResizable]]).

On the other hand,

> I discovered this in a game jam entry I made (https://ianjk.com/ld52/) that I was testing in the Safari Technology Preview. For some reason the SharedArrayBuffer backing the WebAssembly binary is automatically made 'growable' in Safari Technology Preview 160. In Safari 16.2 that does not happen so both the attached example and my game jam entry run fine.


This is fixed in bug 249635.

*** This bug has been marked as a duplicate of bug 249635 ***
Comment 5 Kenneth Russell 2023-01-09 15:33:43 PST 
For what it's worth I think the WebGL IDL should be updated to add [AllowResizable] for compatibility with WebAssembly applications that use resizable memory. Have filed https://github.com/KhronosGroup/WebGL/issues/3510 about this.