222733 - document.config should be renamed to document.domConfig to match the changes in DOM Level 3 Core (not yet published)

Status: RESOLVED FIXED

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

Description

[Christopher Kotran]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007

The following code segment as found on http://upcsuccess.com works in 1.4 and
under IE (used for comparison).  Under Mozilla 1.5, it no longer works.

<a class='link' title='UPC Training' href='javascript:void(0);'
onClick="window.open('http://www.upctraining.com','Training',config='menubar=1,titlebar=0,toolbar=0,status=0,location=0,directories=0,width=700,height=460,maximize=yes,resizable=yes,scrollbars=yes');">Training</a>


Reproducible: Always

Steps to Reproduce:
1.Visit http://upcsuccess.com with Mozilla 1.4
2.Goto bottom (footer) of page.
3.Click on Training OR any other link with an OnClick event.
4.All works fine.
5.Repeat steps with Mozilla 1.5 and no new windows open.

Actual Results:  
The onClick event either did not fire or the window.open did not open a new window.

Expected Results:  
Mozilla should have opened a new window.

Comment 1

[Anne (:annevk)]

Proposed: Invalid.

Your JavaScript is buggy. Try this:

<a class='link' title='UPC Training' href='http://www.upctraining.com'
onClick="window.open(this.href,'Training','menubar=1,titlebar=0,toolbar=0,status=0,location=0,directories=0,width=700,height=460,maximize=yes,resizable=yes,scrollbars=yes');return
false;">Training</a>

Comment 2

[Boris Zbarsky [:bzbarsky]]

Hmm... This should sorta work, actually.  Are there errors in the JS console?

Comment 3

[Anne (:annevk)]

With code provided in comment 0:

> Error: setting a property that has only a getter

Comment 4

[Boris Zbarsky [:bzbarsky]]

Oh, I see.   The problem is that we implemented parts of the DOM3 specification,
and there is a "config" property on the Document object now.  So the code used
to set the "config" variable and the return value of the assignment statement
(the string) got passed to the window.open() call.  But now assigning to
"config" without qualifying it finds document.config (correctly) and assigns to
it... which throws an exception, since document.config is readonly.

Over to evangelism.

Comment 5

[Bob Clary [:bc] (inactive)]

This is going to cause lots of problems. I do not know where this started but a
quick look on google shows lots of hits for people using/recommending that the
way to set the new window features is to pass a config='blah' as a parameter to
window.open. There are even links to educational materials which *taught* people
to do this.

http://www.google.com/search?q=javascript+window.open+config&hl=en&lr=&ie=UTF-8&oe=UTF-8&start=10&sa=N

Why is the config='blah' being used to assign to a variable in the first place?
This is the first time I have seen that behavior mentioned. If document.config
is a property that will stay, then we *must* remove the behavior that an
expression in the window.open parameter list is executed in this way.

Comment 6

[Bob Clary [:bc] (inactive)]

Doh. Ok, the expression is evaluated before the window.open call so that is
where the assignment is happening. Is document.config something we can make
replaceable or can we just ignore assignments to it?

Comment 7

[Hixie (not reading bugmail)]

brendan: replaceable?

Comment 8

[Brendan Eich [:brendan]]

Jst, can you take this as a DOM bug and make document.config replaceable?  Or
give it back to evang, but I bet it's worldwide (so that seems like a non-starter).

/be

Comment 9

[Bob Clary [:bc] (inactive)]

I have been thinking about this a bit more and feel that the most appropriate
change is to the specification. Document overlaps with the DOM 0 use of
HTMLDocument on the web. DOM 3 should not be adding new "unqualified"
properties/methods to Document as they can potentially cause conflicts with
existing code in the wild as this case illustrates. Since we will be the first
(and perhaps) only browser to implement them, these properties/methods will show
up as errors in Mozilla and not other browsers which will increase the cost of
supporting Mozilla. I feel that if the W3 wants to add new properties/methods to
Document that will live in HTMLDocument, then they should be qualified by a
prefix or by another object as in 
Document.w3dom3Config or Document.w3dom3.config or something similar.

Comment 10

[Johnny Stenback (:jst)]

The DOM WG discussed this issue in the last telecon (yesterday) and it was
decided that Document.config should be renamed to Document.domConfig to make
conflicts with existing code on the web less likely. I would suggest that we
simply follow that and see how far that gets us, if we run into more problems
like this, then we'll make Document.domConfig or whatever replaceable to
eliminate this problem once n' for all.

Thoughts?

Comment 11

[Hixie (not reading bugmail)]

sounds good to me

Comment 12

[Boris Zbarsky [:bzbarsky]]

Sounds perfect.

Comment 13

[Boris Zbarsky [:bzbarsky]]

*** Bug 225058 has been marked as a duplicate of this bug. ***

Comment 14

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch to that effect

Comment 15

[Johnny Stenback (:jst)]

Comment on attachment 135059 [details] [diff] [review]
Patch to that effect

r+sr=jst

Comment 16

[Boris Zbarsky [:bzbarsky]]

.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Fixed.

Comment 18

[HJ]

*** Bug 225058 has been marked as a duplicate of this bug. ***