148142 - resetting of document.domain produces "uncaught exception"

Status: RESOLVED WONTFIX

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

Description

[Bengt Nilsson]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; T312461)
BuildID:    2002052309

I've a problem with cross-scripting that could have been solved if it
was allowed to (re)set 'document.domain' to its initial value. E.g. assume the 
initail value of 'document.domain' is 'x.mydom.com'. I set it to 'mydom.com' 
and perform some tasks. If I then try to set it to 'x.mydom.com' I get an 
error. I can't see why this is prohibited.



Reproducible: Always
Steps to Reproduce:
1.Set the document.domain to mydom.com (if it is x.mydom.com initially)
2.Set the document.domain to x.mydom.com
3.

Comment 1

[Henrik Gemal]

http://test.gemal.dk/test/jsdomain.html is a testcase of the problem

first we try to set domain to "gemal.dk" which is a success, but when trying to
reset it to "test.gemal.dk" you get:

Error: uncaught exception: [Exception... "Illegal document.domain value"  code:
"1009" nsresult: "0x805303f1 (NS_ERROR_DOM_BAD_DOCUMENT_DOMAIN)"  location:
"http://test.gemal.dk/test/jsdomain.html Line: 5"]

Comment 2

[Henrik Gemal]

seems like the magic is here:
http://lxr.mozilla.org/seamonkey/source/content/html/document/src/nsHTMLDocument.cpp#1944

Comment 3

[Henrik Gemal]

Internet Explorer display the following:
document.domain is test.gemal.dk
document.domain is gemal.dk
document.domain is gemal.dk

which according to
http://wp.netscape.com/eng/mozilla/3.0/handbook/javascript/ref_d-e.htm#68458
seems right due to:
"Once you change the domain property, you cannot change it back to its original
value. For example, if you change domain from "search.yahoo.com" to "yahoo.com",
you cannot reset it to "search.yahoo.com"."

Comment 4

[Henrik Gemal]

this is caps

Comment 5

[Mitchell Stoltz (not reading bugmail)]

Seems reasonable that you be allowed to change it back.

Comment 6

[Mitchell Stoltz (not reading bugmail)]

Clearing milestone for now.

Comment 7

[Brendan Eich [:brendan]]

This is an incompatibility with IE.  Why not fix it if there's no insecurity?  I.e. let foo.bar.com upgrade to bar.com or com but later downgrade to foo.bar.com. But should we let it change grades to bar.com too?  Why not, since a one-time set of document.domain could achieve that multi-step transition.  Just confirming: what does IE do for such cases?

/be

Comment 8

[Boris Zbarsky [:bzbarsky]]

Yeah, I think the first step is figuring out exactly what IE does.

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Yeah, we should do this, but only if we can make sure we're absolutly certain that we're switching to the right domain. We shouldn't need to navigate through object trees to grab the current docshell through current javascript contexts or anything like that. The data has to be stored in the document or principal directly. 

Comment 10

[Bob Clary [:bc] (inactive)]

Attachment: testcase

Comment 11

[Bob Clary [:bc] (inactive)]

Firefox 1.5
setting domain to mozilla.org
new domain is mozilla.org
setting domain to bugzilla.mozilla.org
Error [Exception... "Illegal document.domain value" code: "1009" nsresult: "0x805303f1 (NS_ERROR_DOM_BAD_DOCUMENT_DOMAIN)" location: "https://bugzilla.mozilla.org/attachment.cgi?id=204646 Line: 25"]

IE6
setting domain to mozilla.org
new domain is mozilla.org
setting domain to bugzilla.mozilla.org
new domain is bugzilla.mozilla.org

but... In IE, once the testcase completes, I can't select any text on the page. If I navigate to a new page, then I can. I need to test if IE actually follows the same domain checks after the domain is reset.

Comment 12

[Bob Clary [:bc] (inactive)]

(In reply to comment #11)

> I need to test if IE actually follows the same domain checks 
> after the domain is reset.

It partially does. For example in IE6/winxpsp2, if a frameset with frame 1 and frame 2 all live on the same server alice.example.com, and frame 1 and frame 2 set their domain to example.com, then frame 1 resets its domain to alice.example.com, frame 1 can still access frame 2's domain, but not its location.

Comment 14

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Dan, do you have the cycles to look at this? It's a web compat thing.

Comment 15

[Daniel Veditz [:dveditz]]

Although different than IE, we (and Opera) do match the WHAT-WG spec:

http://www.whatwg.org/specs/web-apps/current-work/#domain

We should get the spec changed (including notification to Opera and other browser vendors) if we're going to change. Or else WONTFIX.

The trunk disallows setting document.domain to "public domains" (bug 368700); other browsers--including FF2--allow setting document.domain to top-level domains like "com" as does the current spec. Not exactly relevant to this bug, I guess.

Comment 16

[Anne (:annevk)]

Marking WONTFIX as we should not improve document.domain, but rather try to remove it.