WebGL: extension string is available even though Emscripten doesn't implement it

[kainino0x]

Please include the following in your bug report:

Version of emscripten/emsdk:

emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.50-git (9d830e22903a58a97e5aff79e31e05882112f8db)
clang version 18.0.0 (https://github.com/llvm/llvm-project e88a1ce0137bc14b754b86313228fdc48ba737f3)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /Users/kainino/sources/emsdk/upstream/bin

Failing command line in full:
emcc main.cpp -o index.html -g -sUSE_WEBGL2

Full link command and output with -v appended:
No build failure

Repro code: https://github.com/kainino0x/emscripten-extension-bug
Repro page: https://kai.graphics/emscripten-extension-bug/

Chrome Canary (as of 121.0.6153.0) recently enabled 4 new WebGL extensions:
EXT_clip_control
EXT_depth_clamp
EXT_polygon_offset_clamp
WEBGL_polygon_mode
https://chromiumdash.appspot.com/commit/40900b5e6698955aba32af9679519104c3bad20f

Emscripten passes through the extension strings from WebGL, but it does not actually implement the new entry points glClipControlEXT and glPolygonOffsetClampEXT. These will fail to link if you try to use them directly - but they'll return NULL if you try to get them with GetProcAddress, causing a crash in existing builds if they contain code to use these extensions:

EXT_polygon_offset_clamp was available, calling glPolygonOffsetClampEXT...
Uncaught RuntimeError: null function or function signature mismatch
    at index.wasm.__original_main (index.wasm:0x2dad)
    at index.wasm.main (index.wasm:0x2de3)
    at index.js:709:14
    at callMain (index.js:5683:15)
    at doRun (index.js:5733:23)
    at index.js:5744:7

To reproduce this make sure you have an updated Canary and EXT_polygon_offset_clamp is available on webglreport.com.
(If on Mac, you may need to switch to the Metal backend at chrome://flags/#use-angle.)

EDIT: I am going to revert these new extensions from Chrome per my analysis below. Hopefully a repro isn't really necessary but if needed, you can use an older Chromium snapshot:

Follow the Puppeteer instructions here:
https://www.chromium.org/getting-involved/download-chromium/#chrome-for-testing
Or use these snapshots:
https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Linux_x64/1229878/ (not tried)
https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win_x64/1229878/ (not tried)
https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Mac_Arm/1229875/ (although I can't actually get this to work on my ARM mac)
https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Mac/1229878/ (nor these, though I thought they were dual-architecture binaries)

[kainino0x]

cc @juj but I'm going to look into this for a bit.

[kainino0x]

This is known in particular to affect Filament with EXT_clip_control:
https://github.com/google/filament/blob/e7c67d1adb45182a0b7e765a7d90564c26640da9/filament/backend/src/opengl/OpenGLContext.cpp#L281
(my example uses EXT_polygon_offset_clamp because there's a chance we'll revert EXT_clip_control to avoid breaking Filament, at least for now, but we could end up reverting both)

---

Possible solutions I can think of:

1. Implement these new extensions now.
2. Filter out these new extensions from the list Emscripten exposes, until they're implemented. Has code size impact.
3. Filter out everything except known extensions from the list. Has code size impact.
4. Remove unimplemented extensions from gl2ext.h, for example making GL_EXT_polygon_offset_clamp be undefined. (Note we can't just #define GL_EXT_polygon_offset_clamp 0 before gl2ext.h because many programs use #ifdef instead of #if.)

Options 1 and 2 will not guard us against this happening again, unless the WebGL working group adopts a policy that they'll stop reusing the upstream "EXT_" extension names and only use "WEBGL_" extension names.

Perhaps more importantly, none of these will prevent Chrome's shipment of these extensions from breaking existing content (like existing Filament-based renderers). An alternative:

5. Don't ship these extensions in Chrome, get the WG to rename them to WEBGL_ before shipping.

This is maybe technically a bit heavy-handed as a workaround for an Emscripten problem, but given the ecosystem impact I think it is the most prudent.

cc @kdashg

[kainino0x]

Actually, per that analysis, I'm probably going to revert these two new extensions from Chrome. This will make the repro I provided stop working in Canary.

Anyway, that's the end of my investigation for now.

[kdashg]

Emscripten should not be auto-concatenating an EXTENSIONS string from getSupportedExtensions().

[kdashg]

Emscripten should not be auto-concatenating an EXTENSIONS string from getSupportedExtensions().

Please reopen. I don't think this is resolved until this happens.

[juj]

Why?

[kainino0x]

After #20802 Emscripten only constructs EXTENSIONS by concatenating getSupportedExtensions() when GetProcAddress is disabled. This should be OK because any mention of a function that Emscripten doesn't implement will cause a linker error.

When GetProcAddress is enabled, EXTENSIONS is constructed by allowlist.

[kenrussell]

A couple of comments on #20802 indicate that the new build flag GL_ENABLE_GET_PROC_ADDRESS causes problems: Emscripten apps won't build with the new SDK, and once upgraded, can't downgrade to an older SDK.

Given the experience with this bug, it seems risky for Emscripten to automatically pass through support for all of the browser's supported WebGL extensions. Could Emscripten instead make the behavior of GL_ENABLE_GET_PROC_ADDRESS the default now? Remove the toggle, and maintain an allowlist of WebGL extensions on Emscripten's side which are known to work with Emscripten. While this will require apps to upgrade their SDK and recompile if they want to take advantage of new WebGL extensions, this seems reasonable to me - and much safer than the current situation where the browser can accidentally activate untested code paths in Emscripten.

I'm taking the liberty of reopening this issue while making this comment. Not sure of the status of things right now, but perhaps #20802 could be reverted and redone in a way that no new build flag is added. The current status quo is not really workable from the WebGL WG's point of view - we don't want to have to rename every extension that's exposed to the web into the WEBGL_ namespace. Thanks.

[kdashg]

Why?

It is inherently risky to blindly concat the EXTENSIONS string. The blind-concat approach is a hack that mostly worked, but it's caused this backwards compat issue that is pushing your bug upstream into the working group's process for extension naming. Continuing to do so is to continue to exacerbate this issue.

I believe this is not difficult, and it's important to us (the WebGL WG, future users of webgl's extensions), it would really great to just fix this.

[sbc100]

A couple of comments on #20802 indicate that the new build flag GL_ENABLE_GET_PROC_ADDRESS causes problems: Emscripten apps won't build with the new SDK, and once upgraded, can't downgrade to an older SDK.

The issue described in the PR is just how new settings work in emscripten. The solution is the pass GL_ENABLE_GET_PROC_ADDRESS, but only if the SDK version supports that flag.

In terms is backing out #20802, it sounds like your concerns would be alleviated if we simply made GL_ENABLE_GET_PROC_ADDRESS default to true, at least for some period of time? I believe the #20802 already includes allowlist that are talking about, doesn't it? (Isn't that was this is:

emscripten/src/library_webgl.js

Line 747 in f3c8edc

var supportedExtensionsForGetProcAddress = [

)