-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
img tag / HTMLImageElement error event seems fine everywhere? #6395
Comments
I don't follow. html/elements/img.json currently shows true for onerror in Chrome and ≤79 for Edge. |
I came here from the relevant caniuse page as well as the MDN docs page for HTMLImageElement. I was under the impression that this repo contained the backing data for those pages. And in the later PR I referenced I saw "error_event": {
"__compat": {
"mdn_url": "https://developer.mozilla.org/docs/Web/API/HTMLImageElement/error_event",
"description": "<code>error</code> event",
"support": {
"chrome": {
"version_added": false
}, Does that I'm sorry I'm not really familiar with the process here, so I don't know how the file I linked ( |
Usually it does. In this case, it means that whoever created or updated this file didn't bother to look for this event in the inheritance chain. It should be true. |
It looks to me that there was erroneous data in the handwritten table that used to be on MDN and it was ported to browser-compat-data. In the early days, we were less rigorous about checking the data (to complete the migration quickly), so this isn't exactly surprising. I'd welcome a PR that updates Thank you for reporting this! |
I think |
Hum... why is it even listed here? Element/error_event and Window/error_event are the places where this is documented (not sure why it's been split in two pages since both are actually the same, but that's probably for an other issue). Indeed, the error_event that fires on HTMLImageElement is the global Note that some interfaces like MediaElement or MediaRecorder and probably a lot of other ones do have their own error_event (which are correctly documented). |
That may very well be more an indication of a lack of discussion about this issue than evidence of any kind plan or requirement. MDN folks would know more about that. |
Based on what's done in other areas, I'm guessing the solution will be that the MDN page will need to say, "Inherits errors from...". |
The event data was removed in #13006 in favor of the |
@queengooborg do you know how long it's supposed to take for this update to percolate through to the caniuse page? |
That's a question for @Fyrd, I would say. |
I just noticed that the PR you linked merged in October, so I would think that if it fixed the issue (at least for caniuse) it would have showed up by now. Maybe I misunderstand how the data is used? |
The caniuse site is updated every week, but I just discovered that older entries weren't deleted when doing updates. As a result the deletion was basically ignored. Have just fixed that though for future cases. Thanks for bringing that to my attention! |
The data for the
error
event /onerror
property says that most desktop browsers (at least IE, Edge, Chrome) have no support, and FF has only supported it since v51. I don't have any historical data about this, but I tested those 3 browsers today and they all work fine. I also can't find any notes anywhere online saying that support was added in a particular version, so I suspect that the event may have been supported all along and that #388 just had the wrong data to start with.cc: @teoli2003 , @Elchi3 maybe?
Ref: #4724
The text was updated successfully, but these errors were encountered: