-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Warning for probably-buggy WebIDL conversions? #10419
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
Comments
Not sure what kind of fundamental issue you'd be thinking of. Could you be a bit more specific? Or maybe that's what your followup questions are about :)
Yep, no problems. (Especially in a browser, where the console is not observable. In Node, stdout/stderr are observable IIUC, so it feels a bit more iffy---but it's Node's decision to make, how they factor stdout/stderr's observability into API contracts.)
The one that comes to mind for me is that browsers are very wary of creating warning fatigue in their users. We'd need some reason to believe this particular conversion was causing so many bugs that it was really worth using some the user's valuable warning tolerance on it. And when there are other more-deserving targets on the web (e.g., sync XHR), I don't think that ends up being the case. Hope this helps! |
Thanks @domenic that answered all my questions. I mostly wanted to be cautious here and be sure we're not deviating further from the spec |
And just as some further context, TC39 is generally moving away from these implicit conversions; if we expect a number, newer APIs will throw rather silently convert when they get a NaN, or a string, or something else. Similarly for expecting an int and getting a non-int number, etc. Dunno how much WebIDL desires to match this changeover, tho. |
What is the issue with the HTML Standard?
Hey,
Currently looking at web timers
setTimeout
coerces the value NaN to 0. This makes sense (WebIDL conversions).A user has asked for Node.js to warn on passing
NaN
to setTimeout (with a side channel, "to the console" similarly to browser warnings, not in a way that violates the spec from my understanding).Node timers are not web timers (unfortunately) because they were added to Node before the project was as committed as it is now to web standards. However, many people in the project would like to see the timer APIs move closer to web timers and not further away.
One thing that was brought up was: why don't browsers emit this warning?
Basically, I'm here to ask:
Any other context I'm probably missing would also be appreciated :)
The text was updated successfully, but these errors were encountered: