Closed
Bug 1310483
Opened 8 years ago
Closed 8 years ago
URL constructor doesn't parse search params of custom protocol
Categories
(Core :: DOM: Core & HTML, defect, P3)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
mozilla53
People
(Reporter: merihakar, Assigned: baku)
References
()
Details
(Keywords: dev-doc-complete)
Attachments
(2 files, 5 obsolete files)
165 bytes,
application/x-javascript
|
Details | |
31.75 KB,
patch
|
valentin
:
review+
jcristau
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
Given custom protocol, URL contructor doesn't understand the search parameters part of the URL. For example, in Firefox you get the following:
> var u = new URL("doge:amaze?wow=true&such=false");
> u.protocol
> // "doge:"
> u.pathname
> // "amaze?wow=true&such=false"
> u.search
> // ""
whereas in Chrome, pathname and search part of the URL correctly extracted:
> u.pathname
> // "amaze"
> u.search
> // "?wow=true&such=false"
Component: General → DOM: Core & HTML
Product: Firefox → Core
Comment 2•8 years ago
|
||
FWIW, nsSimpleURI only separates the spec to protocol, path and hash.
http://searchfox.org/mozilla-central/rev/d96317a351af8aa78ab9847e7feed964bbaac7d7/netwerk/base/nsSimpleURI.cpp#203
Assignee | ||
Comment 3•8 years ago
|
||
Spec says: If c is "?", set url’s query to the empty string, and state to query state.
Our implementation is wrong.
Flags: needinfo?(amarchesini)
Updated•8 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•8 years ago
|
Priority: -- → P3
Assignee | ||
Comment 4•8 years ago
|
||
Attachment #8806799 -
Flags: feedback?(valentin.gosu)
Comment 5•8 years ago
|
||
Comment on attachment 8806799 [details] [diff] [review]
URL.patch
Review of attachment 8806799 [details] [diff] [review]:
-----------------------------------------------------------------
Sorry for the late feedback, forgot to submit it.
Found 2 bugs at first glance. Didn't look at the code too closely, but overall it looks good.
::: netwerk/base/nsSimpleURI.cpp
@@ +210,5 @@
> return NS_ERROR_OUT_OF_MEMORY;
> }
>
> + if (mIsQueryValid) {
> + if (!result.Append(NS_LITERAL_CSTRING("#"), fallible) ||
? not #
@@ +406,5 @@
> nsSimpleURI::GetPath(nsACString &result)
> {
> result = mPath;
> + if (mIsQueryValid) {
> + result += NS_LITERAL_CSTRING("#") + mQuery;
? not #
Attachment #8806799 -
Flags: feedback?(valentin.gosu) → feedback+
Assignee | ||
Comment 6•8 years ago
|
||
Attachment #8806799 -
Attachment is obsolete: true
Attachment #8808231 -
Flags: review?(valentin.gosu)
Comment 7•8 years ago
|
||
Comment on attachment 8808231 [details] [diff] [review]
URL.patch
Review of attachment 8808231 [details] [diff] [review]:
-----------------------------------------------------------------
There are a few issues with the patch, and it needs a lot more tests.
Also, did you do a try run? I just looking at some of the instances where we QI to nsIURL, and we might be breaking something with this [1]
We can either audit all 84 instances of "<nsIURL>" [2], or create another IDL called nsIURIWithQuery (or similar) that extends nsIURI - adds the filePath attribute, and nsIURL would extend this new IDL. I think this would be more elegant, and less prone to bugs.
[1] http://searchfox.org/mozilla-central/source/browser/components/shell/nsMacShellService.cpp#124
[2] http://searchfox.org/mozilla-central/search?q=%3CnsIURL%3E&case=false®exp=false&path=
::: netwerk/base/nsSimpleURI.cpp
@@ +453,5 @@
> + // The query
> + if (queryPos > -1) {
> + nsresult rv =
> + SetQuery(Substring(path, queryPos,
> + path.Length() - (hashPos > -1 ? hashPos : 0)));
This is wrong. It should be something like ((hashPos > -1) ? hashPos : path.Length()) - queryPos)
I caught this with a simple use case:
var url = new URL("scheme://test/bla/stuff?query#ref");
equal(url.search, "?query") # returned ?que
Before landing please add tests covering all branches, including the setters.
@@ +462,5 @@
> +
> + // The ref
> + if (hashPos > -1) {
> + nsresult rv = SetRef(Substring(path, hashPos));
> + if (NS_WARN_IF(NS_FAILED(rv))) {
Not sure we need the WARN_IF since neither SetQuery of SetRef return an error code except when changing a mutable URI, which can't happen here.
@@ +827,5 @@
> + // Gracefully skip initial hash
> + if (aQuery[0] == '?') {
> + mQuery = Substring(aQuery, 1);
> + } else {
> + mQuery = aQuery;
You also need to check if the string includes #
Otherwise:
var url = new URL("scheme://test/bla/stuff?query#bla1");
url.search = "test#ref"
url.search # returns "test#ref"
url.href # returns "scheme://test/bla/stuff?test#ref#bla1"
Attachment #8808231 -
Flags: review?(valentin.gosu) → feedback+
Assignee | ||
Comment 8•8 years ago
|
||
> There are a few issues with the patch, and it needs a lot more tests.
The test is included in the patch. I added a test in test_url.html.
Attachment #8808231 -
Attachment is obsolete: true
Attachment #8808595 -
Flags: review?(valentin.gosu)
Assignee | ||
Comment 9•8 years ago
|
||
Assignee: nobody → amarchesini
Attachment #8808595 -
Attachment is obsolete: true
Attachment #8808595 -
Flags: review?(valentin.gosu)
Attachment #8808596 -
Flags: review?(valentin.gosu)
Assignee | ||
Comment 10•8 years ago
|
||
Comment on attachment 8808596 [details] [diff] [review]
URL.patch
Review of attachment 8808596 [details] [diff] [review]:
-----------------------------------------------------------------
::: netwerk/base/nsSimpleURI.cpp
@@ +440,4 @@
> }
>
> + // Query cannot be after the Ref
> + if (hashPos > 0 && queryPos > hashPos) {
this must be != -1
Updated•8 years ago
|
Keywords: dev-doc-needed
Assignee | ||
Comment 11•8 years ago
|
||
Attachment #8808596 -
Attachment is obsolete: true
Attachment #8808596 -
Flags: review?(valentin.gosu)
Attachment #8809449 -
Flags: review?(valentin.gosu)
Assignee | ||
Comment 12•8 years ago
|
||
Check the test_url.html comments. There is 1 thing to fix, but it can be a follow up.
Attachment #8809449 -
Attachment is obsolete: true
Attachment #8809449 -
Flags: review?(valentin.gosu)
Attachment #8809620 -
Flags: review?(valentin.gosu)
Comment 13•8 years ago
|
||
Comment on attachment 8809620 [details] [diff] [review]
URL.patch
Review of attachment 8809620 [details] [diff] [review]:
-----------------------------------------------------------------
Apart from a few nits, it looks great! r=me
::: dom/url/URL.cpp
@@ +606,2 @@
> nsCOMPtr<nsIURL> url(do_QueryInterface(mURI));
> + if (url) {
If it QIs to nsIURL it should definitely QI to nsIURIWithQuery, so you can remove this part.
::: dom/url/tests/test_url.html
@@ +409,5 @@
> + url.pathname = "new/path?newquery#newhash";
> + is(url.href, "scheme:path/to/file?query#hash");
> +
> + url.search = "?newquery#newhash";
> + // This is actually wrong. The correct result should be: scheme:path/to/file?newquery%23newhash#hash
Good point. It should be easy to fix it here.
@@ +418,5 @@
> + is(url.href, "scheme:pa%00th/to/fi%00le?qu%00ery#ha%00sh");
> +
> + // pathname cannot be overwritten.
> + url.pathname = "new\0\npath";
> + is(url.href, "scheme:pa%00th/to/fi%00le?qu%00ery#ha%00sh");
We don't need 2 tests that setting the pathname doesn't work :)
::: netwerk/base/nsSimpleURI.cpp
@@ +226,5 @@
> }
> } else {
> MOZ_ASSERT(mRef.IsEmpty(), "mIsRefValid/mRef invariant broken");
> }
> +
Remove whitespace only line.
@@ +816,5 @@
> +{
> + NS_ENSURE_STATE(mMutable);
> +
> + nsAutoCString query;
> + nsresult rv = NS_EscapeURL(aQuery, esc_OnlyNonASCII, query, fallible);
use esc_Query instead of esc_OnlyNonASCII, and remove the search for hashPos.
Attachment #8809620 -
Flags: review?(valentin.gosu) → review+
Comment 14•8 years ago
|
||
Pushed by amarchesini@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/aef4a0fdca31
Implement nsIURIWithQuery for having query part in simple URI, r=valentin
Comment 15•8 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox53:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
Assignee | ||
Comment 16•8 years ago
|
||
Comment on attachment 8809620 [details] [diff] [review]
URL.patch
This patch must be uplifted because it's needed for bug 1321719.
Attachment #8809620 -
Flags: approval-mozilla-aurora?
Comment 17•8 years ago
|
||
Comment on attachment 8809620 [details] [diff] [review]
URL.patch
aurora52+ as prerequisite for bug 1321719.
Attachment #8809620 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 18•8 years ago
|
||
wontfix for beta 51, it seems like a pretty big change along with the work in the other bug.
status-firefox51:
--- → wontfix
status-firefox52:
--- → affected
Comment 19•8 years ago
|
||
bugherder uplift |
Flags: in-testsuite+
Comment 20•8 years ago
|
||
I've added a footnote to the compat tables on the relevant ref pages to make people aware of this bug:
https://developer.mozilla.org/en-US/docs/Web/API/HTMLHyperlinkElementUtils/search
https://developer.mozilla.org/en-US/docs/Web/API/HTMLHyperlinkElementUtils/pathname
I've also added a note to the Fx53 release notes page:
https://developer.mozilla.org/en-US/Firefox/Releases/53#DOM_HTML_DOM
Let me know if this look OK. Thanks!
Keywords: dev-doc-needed → dev-doc-complete
Reporter | ||
Comment 21•8 years ago
|
||
Actually, it was working properly for well-known procotols, so the example in the footnotes (http://z.com/x?a=true&b=false) works as expected even before this fix.
Comment 22•3 years ago
|
||
Even after many update, it is still working fine for https://forex.z.com/hk/tc/whyzcomtrade/trustedtrading.html as well.
You need to log in
before you can comment on or make changes to this bug.
Description
•