1128813 - (new URLSearchParams(null)).toString() should return ""

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[jxck]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.94 Safari/537.36

Steps to reproduce:

run code below in Firefox nightly console.

```
var s = new URLSearchParams(null);
console.log(s.toString())
```


Actual results:

this returns below.

```
"null="
```


Expected results:

in spec of https://url.spec.whatwg.org/#concept-urlsearchparams-new.

it seems new with null will same result with new with "" (empty string).
and empty string returns empty string in firefox nightly.

```
(new URLSearchParams("")).toString(); // ""
```

and I also implement this mostly trace of spec.
in my imp, new with null behave same as new with "".
(https://github.com/Jxck/URLSearchParams/blob/master/test/test.js#L35-L36)

Comment 1

[Boris Zbarsky [:bzbarsky]]

Let's look at the spec.  The IDL for the constructor says:

  Constructor(optional (USVString or URLSearchParams) init = "")

So passing null is the same thing as passing "null".

The prose for the constructor, on the other hand, says:

  If init is the empty string or null, return query.

so it seems to think that "init" can be null.  But the IDL doesn't allow that value here.  This is allowed, obviously; the prose could also define what happens if you pass a Node or whatnot, and it'd just be dead code effectively, but this does suggest that the spec author seemed to think null could end up in this algorithm.

Anne, which is it, exactly?  Should the IDL allow null, or should the prose not mention it?

Comment 2

[Anne (:annevk)]

There was another bit of the specification from where the input could be null, but that changed (though not completely) and I forgot to update all the bits. My bad.

https://github.com/whatwg/url/commit/e2122e8c12529265cef225bcd4824c05f50ab84b