Repository navigation
structuredClone / atob / btoa should throw a TypeError without arguments #41450
Description
Activity
@zloirock, thanks for opening this issue. As far as I understand, these utility methods evolved w/o any standard or official specification. The nearest I can find is the link below.
https://html.spec.whatwg.org/multipage/webappapis.html#atob
By any chance, would you be able to link a more complete specification or should we derive this specification from current web browser behavior?
- changed the title
[-]atob / btoa should throw a TypeError without arguments[/-][+]structuredClone / atob / btoa should throw a TypeError without arguments[/+]on Jan 9, 2022 @DerekNonGeneric the same with
structuredClone. I'm not an expert in Web IDL, but looks like here specified that they should take a required argument, so they should throw an error if the argument is missed. This is the behavior of all actual browsers, so I think that's interpreted correctly.Reacted by Derek LewisFor example, similarly, in the
URLspec we could see thatURLSearchParams#appendshould accept 2 params - and if not, that throws an error everywhere - in Node and all browsers:And the error is not specified directly.
Reacted by Derek LewisAs far as I understand, the WHATWG spec for both of the
atob()andbtoa()functions/methods states that a required argument must be taken and must be a value with the primitive type ofstring.As for the
structuredClone()function, the value can be anything other than specified C++ natives; so I guess it's already giving out the intended output as passing nothing falls back to theundefinedvalue, which it's structured clone isundefined, we could also require the user to pass a value regardless of the fallback behavior by checking the amount of arguments they've passed to the function, but I'm -0 on that.Spec for
atobandbtoa: https://html.spec.whatwg.org/multipage/webappapis.html#dom-atob-dev- Firefox:
TypeError: Window.atob: At least 1 argument required, but only 0 passed - Safari:
TypeError: Not enough arguments - Chromium:
TypeError: Failed to execute 'atob' on 'Window': 1 argument required, but only 0 present. - Deno:
DOMException: Failed to decode base64.
Spec for
structuredClone: https://html.spec.whatwg.org/multipage/structured-data.html#dom-structuredclone- Firefox:
TypeError: Window.structuredClone: At least 1 argument required, but only 0 passed - Safari:
TypeError: Not enough arguments - Chromium:
TypeError: Failed to execute 'structuredClone' on 'Window': 1 argument required, but only 0 present. - Deno:
TypeError: Failed to execute 'structuredClone': 1 argument required, but only 0 present.
It looks like Node.js indeed not aligned with the rest of the ecosystem.
- Firefox:
I think this is the part of Web IDL that defines what should happen: https://webidl.spec.whatwg.org/#es-overloads
If there is no valid overload for the type of value passed in here, then we throw a TypeError.
Reacted by Antoine du Hamel and Derek LewisSure I'll open a quick PR that throws
ERR_INVALID_ARG_TYPEand adds a test good catchI can also add a fix for structuredClone to the PR but I'd rather make a good-first-issue out of it if everyone is OK with it given how straightforward it is maybe?
@benjamingr, do you think it would be best to add a new
ERR_INVALID_ARGS_NUMBERcode first, or do you plan to go w/ERR_MISSING_ARGS? Without the name of this missing argument, it might be tough to determine what to provide to the error for the message text.If you want me to open a PR to include this
ERR_INVALID_ARGS_NUMBERfirst, it might be best since adding a whole new error code seems a bit much for a GFI, and it can be tricky.@DerekNonGeneric I think it's important to understand what
.codeis used for and its importance and I don't think it matters in this case. I just think it's important we should raise aTypeErrorandatobis for browser compatibility anyway so I doubt anyone is checking.codeon anything atob related.That said, if you feel strongly about this feel free to push whatever code you want on that branch or ask that I change it to ERR_MISSING_ARGS both are fine by me :)
Reacted by Derek LewisI'll be happy to take the
structuredClonefix. What would be the error of choice in this case?ERR_MISSING_OPTION('value')orERR_INVALID_ARG_TYPE('value', [...'everything specified in #1'], value)?ERR_MISSING_ARGS? I honestly just care that it's a TypeError and is spec compliant :)Oh right,
ERR_MISSING_OPTIONsounds like an error for a missing key in an options object,ERR_MISSING_ARGSmakes more sense 👍🏻- added a commit that references this issue
on Jan 24, 2022 Only a subset was fixed in the PR - so reopening.
- added a commit that references this issue
on Feb 3, 2022 - added 2 commits that reference this issue
on Feb 8, 2022 - added 2 commits that reference this issue
on Mar 2, 2022 - added a commit that references this issue
on Mar 14, 2022

Version
17.3.0
Platform
MacOS 12.1
Subsystem
global / buffer
What steps will reproduce the bug?
How often does it reproduce? Is there a required condition?
No response
What is the expected behavior?
No response
What do you see instead?
^
Additional information
It's an inconsistency with web standards.