Closed Bug 425318 Opened 12 years ago Closed 12 years ago

JS Error when opening a new tab (only affects debug builds)

Categories

(Firefox :: Tabbed Browser, defect, P2)

defect

Tracking

()

RESOLVED FIXED
Firefox 3

People

(Reporter: cbook, Assigned: Gavin)

Details

(Keywords: regression)

Attachments

(1 file)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008032700 Minefield/3.0pre ID:2008032700

Steps to reproduce:
-> Open a new Tab
-> Check the Error Console

Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMLocation.host]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://browser/content/browser.js :: browser_onSecChange :: line 3819"  data: no]
Source File: chrome://browser/content/tabbrowser.xml
Line: 484

Reproduced on a Mac and Windows Debug Build
Flags: blocking-firefox3?
This is DEBUG only, right? I think I've had a patch for this in my tree for a while...
Flags: blocking-firefox3?
Attached patch patchSplinter Review
nsLocation::GetHost can throw for nsSimpleURIs like about:blank...
Assignee: nobody → gavin.sharp
Status: NEW → ASSIGNED
Attachment #311966 - Flags: review?(mano)
Priority: -- → P2
Hardware: PC → All
Summary: JS Error when i open a new Tab → JS Error when opening a new tab (only affects debug builds)
Target Milestone: --- → Firefox 3
Comment on attachment 311966 [details] [diff] [review]
patch

Simple debug-only fix to avoid unneeded Error Console noise.
Attachment #311966 - Flags: approval1.9?
Comment on attachment 311966 [details] [diff] [review]
patch

a=beltzner
Attachment #311966 - Flags: approval1.9? → approval1.9+
mozilla/browser/base/content/browser.js 	1.1021 
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
I think this is a more general error with nsIDOMLocation.host and nsIDOMLocation.hostname, even in non-debug builds. When the location is an about: page like about:blank, both location.host and location.hostname will cause an NS_ERROR_FAILURE. To see this, just go to about:blank, then enter javascript:location.host or javascript:location.hostname in the address bar.
That's expected behavior, since about: URIs are nsSimpleURIs rather than nsStandardURLs. What would the hostname of an about: URI be, anyways?
Since there is no hostname, it seems like .host should return undefined. That would be more well-behaved than a Javascript call returning a C++ error.
The API in question isn't a pure JS API, it's an XPCOM getter. That means it can be used by C++, which somewhat restricts it's behavior - it must follow XPCOM conventions. Even if we were to make the architectural changes required to change this behavior, and were willing to swallow the compatibility hit that implies, in most cases it wouldn't really help - the difference between checking for undefined and using try/catch isn't significant. Callers need to deal either way.
You need to log in before you can comment on or make changes to this bug.