Web IDL study: detect event handlers with no matching event #785
Conversation
When an interface defines an event handler, there should always be an event named after the event handler that targets the interface. The new `noEvent` anomaly detects situations where the event is missing. The analysis reports the two anomalies mentioned in: w3c/webref#1216 (comment) (The analysis reports additional anomalies when run on the raw extracts. That's normal and due to missing event targets that get added during curation)
src/lib/study.js
Outdated
| @@ -149,6 +149,11 @@ const anomalyGroups = [ | |||
| guidance: 'See the [`[Exposed]`](https://webidl.spec.whatwg.org/#Exposed) extended attribute section in Web IDL for requirements.' | |||
| }, | |||
| { name: 'invalid', title: 'Invalid Web IDL' }, | |||
| { | |||
| name: 'noEvent', | |||
| title: 'Suspicious event handlers', | |||
There was a problem hiding this comment.
| title: 'Suspicious event handlers', | |
| title: 'Event handlers needing review', |
not great either, but "suspicious" feels a bit strong
There was a problem hiding this comment.
I agree "suspicious" isn't good. Looking at the title of this PR, I'm thinking "Event handlers with no matching events" could be a good enough title in practice.
|
The guarantee we could consider for webref would be that each event can be tied to the relevant eventhandler attribute(s) (or be annotated as not having such a thing). Then we could use the naming best practice to fill it by default, and if/when that best practice should fail, we could presumably have an override through the event patching mechanism. With that said, I don't think we have such a demand from any consumer at this point, so I don't think we need to bother with this at this point. |
In the meantime, it could be useful to enable detection of these anomalies within the job, so that we get alerted when a new case arises. One caveat though. The job runs analyses on the raw crawl results and this analysis would better run on the curated results, it's useless (and noisy) to report anomalies that are triggered by another anomaly that we'd have already detected and reported. Amending the job to run a second analysis on the curated branch should be relatively easy. |
As discussed in w3c/webref#1216, when an interface defines an event handler, there should always be an event named after the event handler that targets the interface. The new
noEventanomaly detects situations where the event is missing.The analysis reports the two anomalies mentioned in w3c/webref#1216 (comment)
(The analysis reports additional anomalies when run on the raw extracts. That's normal and due to missing event targets that get added during curation)
I do not know yet to what extent we want to make that a guarantee for the Webref events package. First exception-to-the rule is easy to explain. The second one for
RTCIceTransport.onerrorwill hopefully be fixed at some point, the overall question being: what patching do we do when we bump into a problem that does not get fixed immediately?