Bug 170452 - Setting url.search="??" (two questionmarks) has incorrect behavior
Summary: Setting url.search="??" (two questionmarks) has incorrect behavior
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: Safari Technology Preview
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Rob Buis
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2017-04-04 08:58 PDT by Simon Pieters (:zcorpan)
Modified: 2020-06-28 22:20 PDT (History)
10 users (show)

See Also:


Attachments
Patch (4.15 KB, patch)
2020-06-27 10:07 PDT, Rob Buis
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Pieters (:zcorpan) 2017-04-04 08:58:37 PDT
From https://bugs.webkit.org/show_bug.cgi?id=161191

+FAIL Setting <https://example.net?lang=en-US#nav>.search = '??lang=fr' assert_equals: expected "https://example.net/??lang=fr#nav" but got "https://example.net/?lang=fr#nav"

I noticed today that http://software.hixie.ch/utilities/js/live-dom-viewer/saved/5000 has different results in webkit, chromium, and gecko. :-(

<!DOCTYPE html>
<a href id=a></a>
<script>
a.search='?';
w(a.href);
a.search='??';
w(a.href);
var u = new URL('https://test/');
u.search = '?';
w(u.href);
u.search = '??';
w(u.href);
</script>

Result in Safari TP:

log: http://software.hixie.ch/utilities/js/live-dom-viewer/?
log: http://software.hixie.ch/utilities/js/live-dom-viewer/?
log: https://test/?
log: https://test/?

Expected (per URL standard and as in Gecko):

log: http://software.hixie.ch/utilities/js/live-dom-viewer/?
log: http://software.hixie.ch/utilities/js/live-dom-viewer/??
log: https://test/?
log: https://test/??


(Issue for chromium which has incorrect behavior for url.search = '?' instead: https://bugs.chromium.org/p/chromium/issues/detail?id=682150#c7 )
Comment 1 Alex Christensen 2017-04-05 10:49:01 PDT
We match the behavior of Chromium when setting the query to "??", and if I interpret https://url.spec.whatwg.org/#dom-url-search correctly, then Firefox and the web platform tests are not following the specification:
"Let input be the given value with a single leading U+003F (?) removed, if any."
I interpret this to mean that if the given value starts with one or more '?' then one will be removed.  Firefox seems to interpret this to mean that the leading '?' is only to be removed if it is followed by a non-question-mark character, which I don't think makes any sense.  I'm interested in Anne's interpretation.

With the setting of the query to "?" I believe Firefox, WebKit, and the specification are "correct" and Chromium needs to change.
Comment 2 Anne van Kesteren 2017-04-05 11:09:12 PDT
I think you are correct. I created https://github.com/w3c/web-platform-tests/pull/5387 to fix web-platform-tests. Haven't filed a bug against the other browsers thus far.
Comment 3 Anne van Kesteren 2017-04-06 01:10:21 PDT
Actually, as Simon pointed out in web-platform-tests review, while a leading "?" is removed, the search getter adds it back. So therefore you'd still see two of them.

So this is bug in WebKit after all.
Comment 4 Rob Buis 2020-06-27 10:07:56 PDT
Created attachment 402961 [details]
Patch
Comment 5 EWS 2020-06-28 14:36:10 PDT
Committed r263637: <https://trac.webkit.org/changeset/263637>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 402961 [details].
Comment 6 Radar WebKit Bug Importer 2020-06-28 14:37:13 PDT
<rdar://problem/64867705>
Comment 7 Darin Adler 2020-06-28 14:54:32 PDT
Is URLDecomposition used anywhere else besides the URL, <a>, and <area> cases that are covered by WPT?
Comment 8 Rob Buis 2020-06-28 22:20:03 PDT
(In reply to Darin Adler from comment #7)
> Is URLDecomposition used anywhere else besides the URL, <a>, and <area>
> cases that are covered by WPT?

It is only web exposed to URL, <a>, and <area>. The derived DOMURL is used in internals API and editing/.