Skip to content

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

Closed
benjamingr opened this issue Jun 20, 2024 · 3 comments
Closed

Warning for probably-buggy WebIDL conversions? #10419

benjamingr opened this issue Jun 20, 2024 · 3 comments

Comments

@benjamingr
Copy link
Member

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:

  • 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)?
  • I recall but want to verify - logging to a side channel like this doesn't violate the spec right?
  • Is there a reason other than "no one implemented it" browsers don't emit such a warning?

Any other context I'm probably missing would also be appreciated :)

@domenic
Copy link
Member

domenic commented Jun 21, 2024

  • 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
Copy link
Member Author

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants