1203463 - URL constructor loses path for about: protocol

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Sergey Rashitov]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.124 YaBrowser/15.7.2357.2877 Safari/537.36

Steps to reproduce:

URL('about:blank')


Actual results:

The path "blank" is lost.

URL { href: "about:blank", origin: "null", protocol: "about:", username: "", password: "", host: "", hostname: "", port: "", pathname: "", search: "" }


Expected results:

URL { href: "about:blank", origin: "null", protocol: "about:", username: "", password: "", host: "", hostname: "", port: "", pathname: "blank", search: "" }

See rfc3986 - "3. Syntax Components".
Or rfc1738 - "2.1. The main parts of URLs"

Comment 1

[Benjamin Bouvier [:bbouvier] (inactive)]

Sergey, the Core::JavaScript component is reserved for basic features of the JavaScript language (objects, arrays, strings, global names, etc.) as defined in the ES262 definition. The URL object doesn't fall under this specification, so it's probably related to another component. Tentatively moving back to Location Bar, as Loic did.

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

URL() constructor is DOM.  Its unclear to me how "about:blank" is spec'd in regards to path.

Comment 3

[Anne (:annevk)]

Comment 0 is correct per the URL Standard.

Comment 4

[Boris Zbarsky [:bzbarsky]]

The pathname getter in URL.cpp looks like this:

422   aPathname.Truncate();
423 
424   nsCOMPtr<nsIURL> url(do_QueryInterface(mURI));
425   if (!url) {
426     // Do not throw!  Not having a valid URI or URL should result in an empty
427     // string.
428     return;
429   }
430 
431   nsAutoCString file;
432   nsresult rv = url->GetFilePath(file);

etc.

about:blank is not nsIURL, so the early return is taken.  Sounds like all we want to do is for non-nsIURL things return the GetPath of the nsIURI, no?

Comment 5

[Andrea Marchesini [:baku]]

Attachment: uri.patch

Comment 6

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8661305 [details] [diff] [review]
uri.patch

r=me

Comment 7

[Andrea Marchesini [:baku]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/1023659e3413

Comment 8

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

I had to back this out for various bustages: https://hg.mozilla.org/integration/mozilla-inbound/rev/27cdeffa4ae1

https://treeherder.mozilla.org/logviewer.html#?job_id=14146579&repo=mozilla-inbound
https://treeherder.mozilla.org/logviewer.html#?job_id=14146100&repo=mozilla-inbound

Comment 9

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Also want to pin https://treeherder.mozilla.org/logviewer.html#?job_id=14147726&repo=mozilla-inbound on this patch.

Comment 10

[Andrea Marchesini [:baku]]

  https://hg.mozilla.org/integration/mozilla-inbound/rev/7c1d4c3e68ad

Comment 11

[Andrea Marchesini [:baku]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=5fe225310737

Comment 12

[alta88]

Gtk-WARNING **: Error loading theme icon 'folder' for stock: Unrecognized image file format

this seems to break moz-icon:// urls.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Seems pretty unlikely.

Comment 14

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/7c1d4c3e68ad

Comment 15

[Andrea Marchesini [:baku]]

> this seems to break moz-icon:// urls.

Can you write a test or tell me how to reproduce this issue?

Comment 16

[alta88]

With linux and yesterday's nightly, when opening the history sidebar, for example, and viewing by date and site, the folder icon shows a broken page instead.  First noticed with an update and build of Thunderbird 2 days ago, while the same from 3 days ago was fine. This bug seemed most suspicious in a cursory scan of checkins in that range.

Comment 17

[Boris Zbarsky [:bzbarsky]]

What is the checkin range you were looking at?

Comment 18

[alta88]

http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=3+days+ago&enddate=1+day+ago

Comment 19

[Boris Zbarsky [:bzbarsky]]

Are you sure that's the right range?  What are the actual mozilla-central changeset ids for the working and non-working thing?

(We should probably move this discussion to a separate bug, since I'm 99% sure your problem has nothing to do with this bug.)