Intent to Prototype and Ship: WebGLContextEvent on Web Workers

[Ken Russell]

Contact emails

k...@chromium.org

Explainer

None

Specification

https://registry.khronos.org/webgl/specs/latest/1.0

Summary

The WebGLContextEvent type has been defined in Khronos' WebGL specification for a number of years, but it was not noticed until recently that in Blink, this type is not exposed on web workers. (Most applications simply add an event listener for the type, and do not look for its prototype in the global scope.)

This is a simple fix to Blink's Web IDL for WebGLContextEvent, but is a web exposed change.

Blink component

Blink>WebGL

Motivation

See Summary.

Initial public proposal

None; standardized years ago in Khronos when WebGL support was added to OffscreenCanvas.

TAG review

None; standardized years ago in Khronos when WebGL support was added to OffscreenCanvas.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Gecko: Already implemented

WebKit: Just implemented in https://bugs.webkit.org/show_bug.cgi?id=251504

Web developers: Meet team reported this missing prototype in an internal bug report.

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No

Debuggability

Is this feature fully tested by web-platform-tests?

Yes

Flag name

None

Requires code in //chrome?

False

Estimated milestones

M113

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5071251544997888

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

LGTM1

Thanks for aligning with the spec!

On Wed, Feb 8, 2023 at 1:35 AM Ken Russell <k...@chromium.org> wrote:

Contact emails

k...@chromium.org

Explainer

None

Specification

https://registry.khronos.org/webgl/specs/latest/1.0

Summary

The WebGLContextEvent type has been defined in Khronos' WebGL specification for a number of years, but it was not noticed until recently that in Blink, this type is not exposed on web workers. (Most applications simply add an event listener for the type, and do not look for its prototype in the global scope.)

This is a simple fix to Blink's Web IDL for WebGLContextEvent, but is a web exposed change.

Blink component

Blink>WebGL

Motivation

See Summary.

Initial public proposal

None; standardized years ago in Khronos when WebGL support was added to OffscreenCanvas.

TAG review

None; standardized years ago in Khronos when WebGL support was added to OffscreenCanvas.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

I can't imagine a compat risk here (that is, can't see how reasonable content would rely on the fact that this object is *not* exposed in workers).

From an interop perspective, there's risk if we don't align with the spec and other implementers.

   

Gecko: Already implemented

WebKit: Just implemented in https://bugs.webkit.org/show_bug.cgi?id=251504

Web developers: Meet team reported this missing prototype in an internal bug report.

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No

Debuggability

Is this feature fully tested by web-platform-tests?

Yes

Flag name

None

Requires code in //chrome?

False

Estimated milestones

M113

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5071251544997888

This intent message was generated by Chrome Platform Status.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMYvS2czQWvKTcvph9HNX34LH_V6EerUCLyHWOx-XrTJnar_gQ%40mail.gmail.com.

[Rick Byers]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfU%2BFYwex9_1rhgEpq9SJgsLbOwWj3kyVC92fpswdbJoow%40mail.gmail.com.

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY966bvG78y8Vw%2BTK841AsHn%3DTnPQeG%2B%2BLPTLeHyTxoDUQ%40mail.gmail.com.

[slightlyoff via Chromestatus]

LGTM1 Do we know if other browsers that support offscreen canvas (Safari TP, e.g.) handle this the same way? Or are we the first to ship?

[Kenneth Russell]

Sorry for the delay replying...this email didn't show up in my Inbox nor Spam folder.

The other browsers handle this in the same way. Firefox has supported WebGL on web workers for some time, and Safari had exactly the same IDL bug which they just fixed.

-Ken

[Joshua Bell]

Super low priority question:

We've got WPTs and tooling that slurps Web IDL from specs and validates it against implementations which in theory should have caught this. This is a fairly fragile process (requires spec to be just right, jobs to be configured, tests to exist, integration bots to successfully run it, failures to get bugs filed, humans to triage, etc) so I'm not surprised this was missed, but do you happen to know where in the pipeline we dropped the ball in this case?

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1da41865-85f7-449c-89e2-d000bf509d86n%40chromium.org.

[Ken Russell]

Sorry, not sure. The living WebGL specs are hosted at:

https://registry.khronos.org/webgl/specs/latest/1.0/

https://registry.khronos.org/webgl/specs/latest/2.0/

The IDL is actually auto-extracted from the spec so should be easy to ingest and validate against Blink's.

One other thing to consider is that Blink's IDL might not be exactly identical to the spec's - for example, Blink uses several extended and non-standard Web IDL attributes to optimize the calling convention of certain entry points. I also vaguely recall some issues with overloads that were legal in Web IDL but needed some hackery to build properly in Blink, but not sure about this.

-Ken

[Joshua Bell]

I dug in a bit. Looks like the webgl1 and webgl2 IDLs are indeed extracted by the workflow and placed in https://github.com/web-platform-tests/wpt/tree/master/interfaces (yay!) and the WebXR tests even reference the webgl1 IDLs but there's no idlharness test that actually exercises them. (boo!)

A pretty minimal idlharness test should (...) automagically verify exposure of interfaces in the appropriate global contexts (e.g. you'd have a window.js and worker.js version); that'd be good to add for WebGL - it would have caught this issue. Slightly more elaborate tests mint various objects so the properties can be inspected. You can find examples looking for files named "idlharness.https.window.js" etc in the various Web Platform Test (WPT) dirs: https://github.com/web-platform-tests/wpt

Attention blink-dev lurkers! Adding WPTs is a great way to get started contributing to the web platform, if anyone out there is looking to help out! Plenty of mentors around here to help folks out! Ken and I can probably review.

On Mon, Feb 13, 2023 at 9:00 PM Ken Russell <k...@chromium.org> wrote:

Sorry, not sure. The living WebGL specs are hosted at:

https://registry.khronos.org/webgl/specs/latest/1.0/

https://registry.khronos.org/webgl/specs/latest/2.0/

The IDL is actually auto-extracted from the spec so should be easy to ingest and validate against Blink's.

One other thing to consider is that Blink's IDL might not be exactly identical to the spec's - for example, Blink uses several extended and non-standard Web IDL attributes to optimize the calling convention of certain entry points. I also vaguely recall some issues with overloads that were legal in Web IDL but needed some hackery to build properly in Blink, but not sure about this.

Re: Blink IDL - the good news is that the idlharness WPTs don't look at Blink's IDL at all - they consume the spec's IDL and try to verify that the execution environment they're running in is providing objects that behave as in the IDL, as much as possible. It's not perfect - argument and return types can't be determined, for example - but it can catch many things. Hackery e.g. using overloads to simulate unions shouldn't be an issue, either because neither can be tested properly or because if we get the overloads right they're indistinguishable from the unions, as intended.

But anyway, "simple" things like interface exposure should just work, since they'll compare the spec IDL and assert that the global contains an appropriately named property.

[Philip Jägenstedt]

Hi Josh,

Thanks for taking a look at this and noticing it's kind of fragile and broken :) The idlharness.js setup has evolved step by step from IDL manually copied from specs and inlined into specs, to today's setup of the interfaces/*.idl being updated by automated PRs, but not reviewed/merged automatically. (The latest sync is block, as is common.)

We have all the information (from @webref/idl) we need to generate tests for 99% of what matters, and could do that automatically. However, the current setup needs regular intervention because two things are maintained manually. The first is the dependencies between specs, where foo.idl depends on bar.idl, which could be determined automatically but isn't. The second is the instances of interfaces, which is the idl_array.add_object() calls and all of the required setup.

This could be improved by splitting the automatically generated tests from the bits that need manual setup. In order to not require adding even a boilerplate idlharness.any.js, I think those tests would have to be generated by a build step.

Best regards,

Philip

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD649j6E0Zfo4qZ2vg8TGxeqVYMKWwSaqsUwgg6UpbqjA76ZHQ%40mail.gmail.com.