URLSearchParams parsing seemings to be broken for full URLs

[Derrick Granowski]

I think I found a bug where if you pass a full URL into the constructor of the URLSearchParams in the browser, then you will not receive what you would expect.

Here's how to reproduce:
var s = "https://localhost/?code=123";
var p = new URLSearchParams(s);

p.get('https://localhost/?code');
(produces "123")

p.get('code');
(produces null)

I would have expected the constructor to correctly parse the full URL and build the list of query parameters.

I have identified the section of code in the C++ of webkit that does the parsing of the URL and I believe I can fix it and submit a Pull Request of some sort if asked to, but would like some confirmation if this for a bug.

Thanks,
DG

[Derrick Granowski]

After taking a look with a coworker, they also seemed to have confirmed that they were expecting to see a 'q' and 's' set of keys from a URL 'http://www.google.com?q=hola&s=adios'
and instead got 'http://www.google.com?q' and 's' as keys.

[Alexey Proskuryakov]

Looks like correct behavior to me.

1. Firefox and Chrome work in the same way, and it is rare that three browser engines have the same bug independently.

2. I don't see anything about parsing the input as URL at <https://url.spec.whatwg.org/#urlsearchparams>.

[Derrick Granowski]

Yeah, I was looking deeper at the w3c specifications after I entered this...

Realized that the spec itself defines this behavior. Which I would argue is not the correct behavior, but if that's what someone wrote, then I can't argue against that, and would have to take my opinion to whoever is writing the Request for Comments (RFC).

Thanks,
DG