417021 - document.domain access throws exception in chrome HTML docs

Status: RESOLVED FIXED

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

Description

[AnEeS Bhai]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMNSHTMLDocument.domain]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: javascript:%20alert(document.domain) :: <TOP_LEVEL> :: line 1"  data: no]

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Actual Results:  
Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMNSHTMLDocument.domain]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: javascript:%20alert(document.domain) :: <TOP_LEVEL> :: line 1"  data: no]

Expected Results:  
it should show me the domain of the document open

Comment 1

[Daniel Veditz [:dveditz]]

Throwing a security error rather than doing the unsafe action is the opposite of a security problem: clearing security-sensitive flag

The error console is not tied to any particular page, it will not show you information about "the document open". If you want that functionality you need an addon like the JavaScript debugger "Venkman", Firebug (JS debugger and DOM inspector), or even something lightweight like the "JS Shell" bookmarklet from http://www.squarefree.com/bookmarklets/

in the error console alert(document.location) is "chrome://global/content/blank.html". I'm not entirely sure where the error comes from, but chrome documents don't have a sensible domain. I would have expected an empty string as with local file: uris so there may be a minor bug here. I get the same result loading other chrome .html docs in a browser window so the error console is irrelevant to this effect.

XUL documents don't have a document.domain property, they return "undefined" without throwing an error.

Comment 2

[Godmar Back]

This bug is a show-stopper for us as well.  We tracked it down to the fact that chrome:// pages are backed by the system principal, which is not associated with any domain.

We want to run Google Analytics in a chrome://...html page, and it fails due to this problem.  (Sidenote: in our Google Chrome version, the Google Analytics code runs just fine their so-called background page.)

We would be grateful for any alternatives.  We need to use Google Analytics to collect usage statistics for our extension. To that end, we were hoping to load it into a (hidden) chrome:// page with which we would then communicate via an internal API so that the corresponding calls are issued to track statistics.

How else can our goal be accomplished?

Comment 3

[Godmar Back]

Others are struggling with this as well, see:

http://stackoverflow.com/questions/1770373/google-analytics-to-track-firefox-extension-use
and
http://fartersoft.com/blog/2011/03/11/track-firefox-extension-installation-and-usage-statistics-using-google-analytics/

Comment 4

[msuhr]

I get also this error when using ckEditor within an HTML page.

Is there any workaround fo this?

Comment 5

[msuhr]

An not so good workaround is to override the getter for domain property  but this is very ****.
Sample:
document.__defineGetter__("domain", function() {
  // return value you need or my expected value
  return window.location.hostname;
});

Why not return the value of 'window.location.host'. This is the name of content alias where the HTML is loaded from.

File: chrome://test/content/simple.html
Expected:
document.domain = "test"

Actual:
NS_ERROR_FAILURE

Why is actual the exception thrown and not at least an empty domain returned (but the content alias would be better)?

Comment 6

[Anne (:annevk)]

Per http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#dom-document-domain getting document.domain should not throw.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Fixed by patch in bug 340494.