Mark ondragexit handler and dragexit event as standard_track:false, and deprecated:true

[sideshowbarker]

This change marks the ondragexit event handler and dragexit event as standard_track:false and deprecated:true — because they have now been removed from the HTML spec:

• whatwg/html@40e3868
• Remove ondragexit? whatwg/html#2741

[foolip]

Why should we not keep this entry, and have it be in sync with the ondragexit entry? @ddbeck is there a guidelines for when to have each type of entry, and on what interfaces they should be?

[ddbeck]

I'm not quite sure what it means that onrdagexit is supported, but the dragexit event is not. @sideshowbarker can you elaborate on this?

My instinct says that if there's an event handler then there's probably a corresponding event (unless the event handler receives a different event, or some other oddity), but I don't actually know a lot about event APIs, so I don't know if that's a helpful instinct.

[sideshowbarker]

-       "dragexit_event": { 

Why should we not keep this entry, and have it be in sync with the ondragexit entry?

My preference would be to delete the ondragexit entry too. I don’t think we have evidence that developers are actually relying on it in any way in practice — we don’t have any evidence that they’d miss it if we dropped it.

I'm not quite sure what it means that onrdagexit is supported, but the dragexit event is not. @sideshowbarker can you elaborate on this?

I believe the dragexit event is supported in Gecko — it’s just that we never got around to documenting it as such in BCD. But it’s not supported in any other engines, and never will be. So it’s never been part of the web platform and never will be. For those reasons I don’t think it merits us going out of our way to retroactively document it in BCD in any way.

And given all that, my personal preference would be that we completely delete the ondragexit data too. If we are able to get agreement about that, then I can also add that change to this PR.

[ddbeck]

OK, I guess this is the story as I understand it:

1. The data removed in this PR (the event itself) reports false for all browsers. But this data is erroneous, at least for Firefox—Gecko implemented it, but BCD never reflected that.
2. The PR leaves intact data for the ondragexit handler. The data for that is either strange in some way which we haven't documented (browsers other than Firefox use ondragexit as a handler for a different event or something else), or wrong (browsers other than Firefox don't implement ondragexit in any way).

But, if as you say, Firefox is the only browser that implemented ondragexit and it's still available today (it seems to be, though I'm basing that solely on the console tab completion for ondragexit), then we should:

1. Have features for both ondragexit and the dragexit event
2. Populate those features with false values for all the other browsers. If we're able to, set the correct values for Firefox, or open a help-wanted issue if we can't be bothered right now.
3. Set the status flags to show this is non-standard, non-experimental, and deprecated.

It's a bit of a bummer—I'd be happier if Firefox removed it so we could bin the features themselves—but I think that's what we're stuck with, if a browser is actually shipping it. In terms of documentation on MDN itself, I don't think it's worth anyone's time to actually update those docs, except maybe to add deprecation notices where there are pages.

[ddbeck]

Sorry, @sideshowbarker I realize I kinda dropped a wall of text on you here. Is this too much? As an alternative, we could pare this down to the status change only, then open an issue to address the feature data at a later time.

(or if you just hadn't got back to this yet, that's fine too)

[foolip]

Per Confluence, the ondragexit event handler attributes are still in Firefox.

[sideshowbarker]

As an alternative, we could pare this down to the status change only

OK, I’ve amended and pushed the commit in this PR branch to only contain a change to the standard_track and deprecated values.

then open an issue to address the feature data at a later time.

OK, opened #6826 for that

[foolip]

Pulling this out from #6710 (comment) so that I can link to it later:

My instinct says that if there's an event handler then there's probably a corresponding event (unless the event handler receives a different event, or some other oddity), but I don't actually know a lot about event APIs, so I don't know if that's a helpful instinct.

@ddbeck This is only usually right, and something odd is going on if a api.**.onfoo entry doesn't match the api.**.foo_event entry. However, there's no necessary connection between them. Here's how I interpret them:

• The onfoo entries are straightforward, we treat them like any other Web IDL attributes (but there are messy cases like How to represent changes/moves on the prototype chain #3463)
• The foo_event entries don't cleanly map to anything machine readable on spec or implementation side, but I interpret them as "can the browser ever fire event with this type at an event target of the type the entry is on". So api.Document.dragexit_event means "can the browser fire a 'dragexit' event at an instance of Document, HTMLDocument or SVGDocument?"

One complication is that the event targets aren't necessarily the same as where the event handler attributes are. Take "volumechange" as an example:
https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/volumechange_event
https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers ('onvolumechange' on that page)

Even setting that complication aside, the two things can easily come apart in implementations. It's easy to forget to add the onfoo attributes, and such mishaps have shipped, making it necessary to use addEventListener. https://chromium.googlesource.com/chromium/src/+/d0d175487822ae4ec8a217a6aa8abe8ab78da02e is an example of a problem like this being fixed.

It's also possible to have the reverse problem, where one copy-pastes some event handler attributes into an implementation, but nothing ever fires those events. I don't have an example of that, but would be shocked if it hasn't happened.

These distinctions are ones that most of the time one need not know about, but as long as BCD represents both things, reviewers will need to be aware of some of this. Perhaps we should write this down in a data guideline?

[foolip]

A real case of onfoo vs foo_event mismatch came up just now in #6833 :)

[ddbeck]

Thank you for your work on this, @sideshowbarker. I'll try to get to #6826 soon, so that we can resolve the broader issues properly. 👍