whatwg / html

HTML Standard
https://html.spec.whatwg.org/multipage/
Other
8.09k stars 2.66k forks source link

Warning for probably-buggy WebIDL conversions? #10419

Closed benjamingr closed 4 months ago

benjamingr commented 4 months ago

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 :)

domenic commented 4 months ago
  • Is there a fundamental issue with emitting a warning (console.warn in browsers speak) when performing this sort of quirky conversion (like NaN to 0)?

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 :)

  • I recall but want to verify - logging to a side channel like this doesn't violate the spec right?

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.)

  • Is there a reason other than "no one implemented it" browsers don't emit such a warning?

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!

benjamingr commented 4 months ago

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

tabatkins commented 3 months ago

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.