URL constructor loses path for about: protocol

RESOLVED FIXED in Firefox 43

Status

()

Core
DOM
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: Sergey Rashitov, Assigned: baku)

Tracking

40 Branch
mozilla43
Points:
---

Firefox Tracking Flags

(firefox43 fixed)

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
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"

Updated

2 years ago
Component: Untriaged → Location Bar
(Reporter)

Updated

2 years ago
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

Comment 2

2 years ago
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 3

2 years ago
Comment 0 is correct per the URL Standard.

Updated

2 years ago
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)
(Assignee)

Comment 5

2 years ago
Created attachment 8661305 [details] [diff] [review]
uri.patch
Flags: needinfo?(amarchesini)
Attachment #8661305 - Flags: review?(bzbarsky)
(Assignee)

Updated

2 years ago
Assignee: nobody → amarchesini
Comment on attachment 8661305 [details] [diff] [review]
uri.patch

r=me
Attachment #8661305 - Flags: review?(bzbarsky) → review+
(Assignee)

Updated

2 years ago
Keywords: checkin-needed
(Assignee)

Comment 7

2 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/1023659e3413
Keywords: checkin-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
Flags: needinfo?(amarchesini)
Also want to pin https://treeherder.mozilla.org/logviewer.html#?job_id=14147726&repo=mozilla-inbound on this patch.
(Assignee)

Comment 10

2 years ago
  https://hg.mozilla.org/integration/mozilla-inbound/rev/7c1d4c3e68ad
Flags: needinfo?(amarchesini)
(Assignee)

Comment 11

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

Comment 12

2 years ago
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
Last Resolved: 2 years ago
status-firefox43: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
(Assignee)

Comment 15

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

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

Comment 16

2 years ago
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)

Comment 18

2 years ago
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=3+days+ago&enddate=1+day+ago
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.)

Updated

2 years ago
Blocks: 1205741

Updated

2 years ago
Flags: needinfo?(alta88)
No longer blocks: 1205741
You need to log in before you can comment on or make changes to this bug.