Closed Bug 562433 Opened 10 years ago Closed 9 years ago

Change location.host and location.hostname to return "" for host-less URIs instead of throwing

Categories

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

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla2.0b4

People

(Reporter: pascal, Assigned: wesongathedeveloper)

References

Details

(Keywords: html5, Whiteboard: [good first bug])

Attachments

(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100428 Minefield/3.7a3pre Firefox/3.6 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100428 Minefield/3.7a3pre Firefox/3.6 (.NET CLR 3.5.30729)

Using JavaScript open a new window, save the reference in a a variable and immediately try to access the location.host or location.hostname property. Generates JavaScript error in console.


Reproducible: Always

Steps to Reproduce:
1. win = window.open('win.html','TestWin','width=800,height=600');
2. access win.location.hostname or win.location.host
3.
Actual Results:  
[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMLocation.host]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: http://localhost/Test.html :: newWin :: line 21" data: no]

Expected Results:  
location.host and location.hostname information of the newly created window
Attached file testcase
> location.host and location.hostname information of the newly created window

The location of the window at the point when you're examining it is "about:blank".  What, exactly, do you expect as the host?

It looks like webkit reports "" as the host, which doesn't really make any sense either.  Opera seems to report the post-load location, which may be true for them; no idea.
Note that the HTML5 spec almost certainly defines how the Location object should behave for thingsl like about:blank.
Without digging deep into the HTML5 spec (so please correct me if I'm wrong), the expected result should either be the host information after load or if location is about:blank the host information of the creator.
Looks like the current HTML5 spec text calls for "" to be returned here.  See http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#interfaces-for-url-manipulation and the link to that from http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#dom-location-host

Of course that depends on the current address bit, but that's unambiguously about:blank in this case.  See http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#dom-open and the steps at http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate and particularly step 12.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: NS_ERROR_FAILURE accessing location.host, location.hostname of created window → Change location.host and location.hostname to return "" for host-less URIs instead of throwing
Whiteboard: [good first bug]
Attached patch Patch (obsolete) — Splinter Review
w.close in the test doesn't close the new window, does it need special privileges?
Assignee: nobody → wesongathedeveloper
Status: NEW → ASSIGNED
Attachment #450200 - Flags: review?(bzbarsky)
> w.close in the test doesn't close the new window, does it need special
> privileges?

No.  It should work.
Comment on attachment 450200 [details] [diff] [review]
Patch

This looks fine, though s/is not/should be/ in the test messages, please.  And you don't need the wait/finish stuff, do you?
Attachment #450200 - Flags: review?(bzbarsky) → review+
Attached patch PatchSplinter Review
addressed above issues
Attachment #450200 - Attachment is obsolete: true
Keywords: checkin-needed
http://hg.mozilla.org/mozilla-central/rev/fc754baf4c59
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Flags: in-testsuite+
OS: Windows 7 → All
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b4
You need to log in before you can comment on or make changes to this bug.