Closed Bug 1203463 Opened 4 years ago Closed 4 years ago

URL constructor loses path for about: protocol

Categories

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

40 Branch
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla43
Tracking Status
firefox43 --- fixed

People

(Reporter: 4b.69.6d.6f, Assigned: baku)

Details

Attachments

(1 file)

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"
Component: Untriaged → Location Bar
Component: Location Bar → JavaScript: Standard Library
Product: Firefox → Core
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.
Component: JavaScript: Standard Library → Location Bar
Product: Core → Firefox
URL() constructor is DOM.  Its unclear to me how "about:blank" is spec'd in regards to path.
Component: Location Bar → DOM
Product: Firefox → Core
Comment 0 is correct per the URL Standard.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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?
Flags: needinfo?(amarchesini)
Attached patch uri.patchSplinter Review
Flags: needinfo?(amarchesini)
Attachment #8661305 - Flags: review?(bzbarsky)
Assignee: nobody → amarchesini
Comment on attachment 8661305 [details] [diff] [review]
uri.patch

r=me
Attachment #8661305 - Flags: review?(bzbarsky) → review+
Keywords: checkin-needed
Gtk-WARNING **: Error loading theme icon 'folder' for stock: Unrecognized image file format

this seems to break moz-icon:// urls.
Seems pretty unlikely.
https://hg.mozilla.org/mozilla-central/rev/7c1d4c3e68ad
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
> this seems to break moz-icon:// urls.

Can you write a test or tell me how to reproduce this issue?
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.
What is the checkin range you were looking at?
Flags: needinfo?(alta88)
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.)
Blocks: 1205741
Flags: needinfo?(alta88)
No longer blocks: 1205741
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.