Fallback findCanvasEventTarget to findEventTarget

[JoeOsborn]

Also fix canvas tag lookup bug, which would return a string rather than an offscreenCanvases entry.

Fixes #22942 , seemingly with no other patches needed; call sites already have to handle a variety of object shapes out of this function.

[sbc100]

This line looks like it might be more complex that it needs to be.

About just target == 'canvas' && Object.values(GL.offscreenCanvases)[0]?

Can we make this a separate PR? Ideally with a test. I guess we have very little testing for this since the existing code seems simply broken?

[JoeOsborn]

I agree with that change and will push it here, but I think this whole lookup thing is pretty hacked together/"best effort".

[JoeOsborn]

As for a test which shows the bug, I guess there are two bugs here---one is that there's no use of specialEventTargets, and the other is that tag lookups are broken. I'll prepare one parameterized test for findCanvasEventTarget, varying on whether it's an ID, a tag, or a special target, both before and after an offscreen canvas has been created.

[JoeOsborn]

I've added a set of tests that fails when the old function definition is in place, and passes with the new definition.

[sbc100]

Is this also missing the .canvas similar to in #22958

[JoeOsborn]

I was worried it would, but in fact we want the whole offscreenCanvases entry because the caller might need the shared canvas pointer. All of the callers do a check for the presence of an .offscreenCanvas field.

[sbc100]

Seems correct to. We should probably wait on @juj for approval though

[JoeOsborn]

I mentioned this on Discord, but we actually have a big problem here: specialHTMLTargets is likely to only have reasonable values on the main thread, since it isn't shared across workers and probably will be configured using MAIN_THREAD_EM_ASM or something (at any rate, it's possible it would be set up on one thread and used on a different thread, which has the same issue). So a findCanvasEventTarget (or indeed a findEventTarget) won't do what we want for canvases that are referred to by specialHTMLTarget names. Only ID lookups or tag lookups actually work.

It seemed like it was working because !canvas was the suggested special name and the ID of the objects involved has typically been #canvas, and the offscreenCanvases array is keyed by the ID of the element involved. So stripping the first character from the ID ends up being like a pun in that case.

What's the right solution? To key offscreenCanvases based on target, rather than canvas ID? To ignore specialHTMLTargets completely in findCanvasEventTarget?

[JoeOsborn]

Just wanted to ping here—I’m a bit stuck because I’m not sure what the right behavior should be.

[JoeOsborn]

Can I get some feedback on this one? I was stuck because the correct behavior isn't clear and I'd like a maintainer to weigh in.

[sbc100]

I'm afraid this is at the limits of my understanding too. However it does seem expected/understandable that the list of specialHTMLTargets would be thread-specific since canvases themselves are thread specific and any given thread could have a different set of them.

Is the issue that you new test is failing in a certain configuration? Or is this more of a general concern that this is the wrong fix?

[JoeOsborn]

I agree it makes sense that special targets would be thread specific, but it complicates the handoff from main to proxy thread (on screen to offscreen canvas) in a proxy to pthread situation. So the options seem to be:

1. Use the deprecated lookup strategy for findCanvasEventTarget, where #canvas means something special and not the html element with ID canvas
2. Proxy accesses to specialHTMLTargets to the main thread, or proxy all calls to find*EventTarget to the main thread; but then we can’t easily get the offscreencanvas after it’s been transferred, right?
3. Make the offscreenCanvases dictionary keyed on target selector strings rather than IDs. This means selectors besides IDs or !IDs won’t always do the right thing in that two queries that should produce the same canvas/offscreenCanvas might not—probably better to require that canvases have either an ID or are in the specialHTMLTargets, so that an identifier or !identifier will uniquely identify the canvas.
4. Eliminate findCanvasEventTarget and replace its uses with either the regular findEventTarget or a function to get a specific offscreencanvas.
5. Return offscreen canvases as numeric handles or something so that client code is responsible for maintaining references to them, and we don’t need findCanvasEventtTarget anymore?

Other ideas I’m not thinking of? It’s been a minute since I was deep into this bug.

[sbc100]

I agree it makes sense that special targets would be thread specific, but it complicates the handoff from main to proxy thread (on screen to offscreen canvas) in a proxy to pthread situation.

Just to be clear, is this something that doesn't work today? And never has worked?

[JoeOsborn]

Yes, I believe it only worked if you used specialHTMLTarget[“!canvas”] specifically because canvas is also an element name and likely because #canvas is special cased in the lookup code. The offscreencanvas would be keyed by “canvas” in the offscreenCanvases map, and by luck it would be retrieved by !canvas (special target) after the ! was trimmed off and produced “canvas”, an element name selector, since the specialHTMLTargets map would be empty in all threads but the main thread.