Running STP through emunittest suite, some of the tests fail with an error TypeError: null is not an object (evaluating 'program.name=id') in Emscripten WebGL library function glCreateProgram: function() { var id = GL.getNewId(GL.programs); var program = GLctx.createProgram(); program.name = id; GL.programs[id] = program; return id; }, Here GLctx is WebGLRenderingContext, and the return of GLctx.createProgram() comes out as null, causing the next line after that to fail. The issue can be reproduced on project http://clb.confined.space/emunittest_unity/Tanks_20191004_152744_wasm_release_profiling.zip
<rdar://problem/67817170>
I'll take this one.
The context is lost. Looks like some texture uploads are triggering some GL errors in ANGLE (probably a different bug), and then GraphicsContextGLOpenGL::reshape() is bailing out because it assumes the GL error was caused by something it did. Easy fix, we can call moveErrorsToSyntheticErrorList() at the top of reshape(). Patch forthcoming.
Created attachment 407358 [details] Patch
Comment on attachment 407358 [details] Patch This fixes it. Need to write a test though.
Comment on attachment 407358 [details] Patch The fix looks good! Thanks in advance for writing a WebGL conformance test. r+
Created attachment 407518 [details] Patch
Comment on attachment 407518 [details] Patch Added a test.
Also I found and fixed the texture upload error issue in bug 215973. Seems like the Unity Tanks demo assumes that S3TC support implies S3TC sRGB support, which is technically wrong but probably should be true these days.
Comment on attachment 407518 [details] Patch Great diagnosis, fix and test James! One slight concern - if WebKit's WebGL conformance suite snapshot is rolled forward again using the LayoutTests/webgl/generate-webgl-tests.py script, your changes to LayoutTests/webgl/2.0.0/resources/webgl_test_files/conformance/canvas/render-after-resize-test.html will be overwritten, since that script simply copies the files into the WebKit repository, ignoring whether any changes were made locally. Now, any future rolls of this test snapshot will likely be small, since it's not under active development. Could you still think a little bit about this and decide whether it's worth preventing accidents in this area? Thanks.
True. Maybe I can just update the test in the 2.0.0 snapshot upstream.
Actually it looks like this test isn't included in the upstream 2.0.0 snapshot, so it won't be overwritten by the script.
Committed r266362: <https://trac.webkit.org/changeset/266362> All reviewed patches have been landed. Closing bug and clearing flags on attachment 407518 [details].