Implement a variety of event interfaces

[domenic]

Previously, we've avoided implementing these ahead of implementing their full spec.

However, it seems like they're popular requests, and it probably doesn't hurt too much to add them. We'll do a major version release to make sure.

[domenic]

Implementation report:

This, like other omnibus tasks where I put together many issues, took longer than expected. (180 minutes with AI, vs. my original estimate of 45 minutes with AI / 120 minutes without AI.)

AI saved me a bit of time in a few cases here. But overall I was not impressed with the performance of AI on this set of issues. They were all fairly simple, but the AIs stumbled a lot.

I tried Cursor with Sonnet 3.7 non-max for the first few events, and it did OK. For the first event (BlobEvent) it over-generated unnecessary code and I told it to follow the example more closely. For PromiseRejectionEvent it kept trying to generate from "memory", ignoring the spec I told it to read---it wasn't able to copy the [Exposed=*], insisting on [Exposed=(Window,Worker)]. Asking it to check more closely resulted in it doubling down, somewhat surprisingly.

So I gave up on AI assistance for the next few commits because it felt simpler to just do it myself.

I then switched to gemini-2.5-pro-exp-03-25 for TransitionEvent, which was a simple copy-the-pattern, and it encouragingly figured it out. Similarly for DeviceOrientationEvent, which was basically the same.

DeviceMotionEvent is more complex, as it involves two auxiliary classes, and I was happy to have Gemini do the work for me. It created all the auxiliary files and classes correctly, but didn't get their integration into the DeviceMotionEvent code correctly the first time. After I suggested the right strategy though, it was fine.

PointerEvent was also slightly complex. Here Gemini came up with a more-complex-than-necessary solution the first time, and after I prompted it to simplify, it did so nicely.

In general I think I could have benefited from briefing Gemini more on the capabilities of the webidl2js binding layer, as Gemini kept assuming it had to insert more conversion code than was necessary. (The binding code generates it.) Part of why I didn't brief Gemini in this way is that Gemini seemed to understand the concept, sometimes, talking about the impl/wrapper separation as if it understood it, and prompting me to re-run the build tools to generate the wrapper code.

The final commit, which implements passive-by-default, went relatively poorly with AI assistance. I was optimistic that this was a tightly-enough scoped problem, but with enough complexity, that it would prove a good challenge. I pointed Gemini at the spec, and told it to update our implementation to match. It... did not really do that. It created some code that vaguely resembled the intent of the spec, but it did not echo the spec's structure, or names, or even type signatures. It completely missed the important part of the passive event listener identification function, which checks the event target, instead focusing only on the event type. I ended up accepting a few of its changes but mostly rewriting what it created from scratch. Overall, it felt like Gemini was really failing at the given task of "implement this spec", instead choosing to use its memory of how this part of the web platform worked to kind of make stuff up.

A final thing to note is that in all of these cases, I found the tests to enable manually, by searching through the web-platform-tests GitHub repository and editing the to-run.yaml expectations file myself. I anticipate that such a task would require more domain knowledge of the project than I was willing to load into context, and the slow round trip as Cursor tool-uses its way through various directories searching for the right tests to enable would take quite a while. Each case took me, as a human, about 2 minutes to find and enable the test, plus a few more to run it.