Bug 170452

Summary:

Setting url.search="??" (two questionmarks) has incorrect behavior

Product:

WebKit

Reporter:

Simon Pieters (:zcorpan) <zcorpan>

Component:

WebCore Misc.

Assignee:

Rob Buis <rbuis>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

achristensen, annevk, cdumez, changseok, darin, esprehn+autocc, ews-watchlist, gyuyoung.kim, rbuis, webkit-bug-importer

Priority:

Keywords:

InRadar

Version:

Safari Technology Preview

Hardware:

Unspecified

OS:

Unspecified

Attachments:

Description	Flags
Patch	none

Simon Pieters (:zcorpan)

Reported 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 )

Attachments
Patch (4.15 KB, patch) 2020-06-27 10:07 PDT, Rob Buis	no flags	Details Formatted Diff Diff
View All Add attachment proposed patch, testcase, etc.

Alex Christensen

Comment 1 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.

Anne van Kesteren

Comment 2 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.

Anne van Kesteren

Comment 3 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.

Rob Buis

Comment 4 2020-06-27 10:07:56 PDT

Created attachment 402961 [details] Patch

EWS

Comment 5 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].

Radar WebKit Bug Importer

Comment 6 2020-06-28 14:37:13 PDT

<rdar://problem/64867705>

Darin Adler

Comment 7 2020-06-28 14:54:32 PDT

Is URLDecomposition used anywhere else besides the URL, <a>, and <area> cases that are covered by WPT?

Rob Buis

Comment 8 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/.

Note You need to log in before you can comment on or make changes to this bug.