Quoting https://url.spec.whatwg.org/#url-serializing

>6. If url’s query is non-null, append U+003F (?), followed by url’s query, to output.

Quoting https://url.spec.whatwg.org/#url-class

>The "search" attribute’s getter must run these steps:
>1. If context object’s url’s query is either null or the empty string, return the empty string.
>2. Return U+003F (?), followed by context object’s url’s query.

In other words "?" should appear in an URL only when query is not null/empty.
So according to the spec the observed behavior is correct, right?
Both Chrome and Firefox interpret the spec in this fashion.

You want to follow the requirements from https://url.spec.whatwg.org/#dom-urlsearchparams-delete onwards. The search attribute is not what is failing in this test.

#2, I believe I already did, just skipped the obvious parts, but to elaborate let's quote https://url.spec.whatwg.org/#dom-urlsearchparams-delete

>1. Remove all name-value pairs whose name is name from list.
>2. Run the update steps.

The update steps:

[...]
>3. Let output be the empty string.
>4. For each tuple in tuples: << there's none in the reported case
>5. Return output.

So in the end the query is an empty string and c#1 applies.

I've mentioned the "search" attribute only because it's the only place in the spec that explicitly mentions both "null" and "empty string" and because keeping "?" in an URL with no search parameters would contradict the very same spec's recipe for the "search" attribute.

> In other words "?" should appear in an URL only when query is not null/empty.

False. URL serialization[1] (url.href) isn't the same as concatenating all of the URL attributes. While the "search" setter treats null and empty the same way, "?" appears in a serialized URL only if query is non-null, including when the query is an empty string.

[1]: https://url.spec.whatwg.org/#concept-url-serializer

Ugh never mind my last comment (5). English is indeed a confusing language.

#4, I see. But since we can't set .searchParams of an URL instance to null, how does the browser discern between an empty string and null for the "query"? It seems you imply that to be spec-compliant the browser should set "query" to null somehow when the URL string used in URL class constructor did not have the question mark initially. The spec doesn't seem to describe any such attribute so if the browsers implement that internally there would be no spec-compliant way to reset/modify that property in JavaScript code unless it's added to the spec, right?

To demonstrate the confusion described in c#7:

  u = new URL('http://example.com/')
  u.searchParams.set('foo', 'bar')
  u.searchParams.delete('foo')

The bug report says u.href should retain the question mark here: "http://example.com/?"
The spec as it is now doesn't seem to provide a way to strip the question mark,
so the web developers would have to resort to ancient string/regexp manipulation, right?

[...continued]

...or explicitly clear an already empty (according to the spec) u.search:
  u.search = ''

in which case u.href loses the question mark.
Not sure this is any better than string/regexp manipulation on u.href because emptying an already empty string looks like a kludge/hack.

url.search = '' removes the ?

url.search = '?' restores it.

In the first case, the setter sets the query to null, then directly returns.

In the second case, the setter sets the query to null, then strips ? and sets the query to the result (the empty string).

#10, yes, and both statements will leave url.search empty in its getter, which is the only way to access the value for a web developer. And in both cases URLSearchParams object of the URL instance is the same. By maintaining the "null" case via this kludgy workaround, the only way to discern whether "query" is empty or null for a web developer is to check url.href string for the presence of the question mark, which is what my comments 7,8,9 are about. Doesn't seem to be a good API. As a web developer I think that the current implementation in Chrome and Firefox is what I would expect since there is no need for "?" in an URL when there are no parameters. Are there any real use cases when "?" without any parameters is desirable?

What about the following solution?
1. Change the API so that the "search" attribute preserves an explicitly set lone "?"
   (the spec case of "query" being an empty string, not null)
2. Fix the browsers so that the final URL preserves "?" when there are no parameters.

Since there will be no currently present ambiguity in the "search" parameter getter, the web developers would have a consistent and *obvious* method of adding/removing the lone "?" in the final URL via setting/clearing url.search attribute, which I believe would solve both the reported bug and the weirdness of the API.

...weirdness and ambiguity of the API, which I've tried to explain in my comments above, is that since the specification represents "query" only via URLSearchParams object of an URL instance and hides a lone "?" in "search" attribute, the API doesn't provide a way to tell whether an arbitrary URL object has a null or empty "query" (in both cases the exposed URLSearchParams object is the same) without checking the "href" attribute via string/regexp methods, but that's a hackish and kludgy workaround a web developer would expect in the '90s, not today.

OTOH, changing the spec's "search" parameter (c#12) is likely to break some existing code like "if (url.search) { ... }" so my idea above is most probably bad. It might be better to add an additional property to indicate that "query" is actually null, for example an actual "query" property that can be null, or an empty string, or a serialization of URLSearchParams.

[mac bug triage]

Tentatively tagging this Blink>Network for URLSearchParam API, please help triage if incorrect.

woxxom@ and timothygu99@, thank you for investigating the issue, but it's better to have the discussion at the URL spec repo.

Found one. https://github.com/whatwg/url/issues/332

Marked as "Available" since Chrome is not conforming to the spec.

Given various questions from developers above, it seems some discussion should happen at the spec side before "fixing".

tyoshino@, thanks for triaging. A discussion around this specific behavior has already happened at https://github.com/w3c/web-platform-tests/pull/6445, but we hopefully will come to a better consensus in https://github.com/whatwg/url/issues/332.

This is now invalid per change to the standard and Chrome passes the new tests (except for sort() which doesn't appear to be implemented).