99571 - Cant navigate http://www.shades.dk/

Status: RESOLVED DUPLICATE of bug 222191

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

Description

[Henrik Gemal]

Nuthing happens when pressing the menuitems on http://www.shades.dk/

build 20010910

---
Error: parent.Text.location has no properties
Source File: http://www.shades.dk/menu.asp
Line: 21

Comment 1

[Doron Rosenberg (IBM)]

Text is the name of the right hand frame.

parent.Text.location.href=(strUrl + '.asp')

Comment 2

[Asa Dotzler [:asa]]

->networking.

Comment 3

[benc]

-> javascript engine.

based on error message.

Comment 4

[neeti]

javascript engine

Comment 5

[Henrik Gemal]

Attachment: minimal testcase. (file 1 - frameset)

Comment 6

[Henrik Gemal]

Attachment: minimal testcase. (file 2)

Comment 7

[Henrik Gemal]

The problem is this:
you have a frameset with a frame named "Text"
the you from on of the files inside the frameset tries to do:
document.writeln(parent.Text.location.href);
you get nothing with Mozilla but the filename in IE. A bug in DOM?

Comment 8

[Phil Schwartau]

Setting default owner and QA -

Comment 9

[Johnny Stenback (:jst)]

Attachment: testcase that works from bugzilla.

Comment 10

[Johnny Stenback (:jst)]

The reson parent.Text.location.href="..." doesn't work in mozilla is that
parent.Text resolves to the constructor function for the "Text" class. This is
how 4x works too, but there's no "Text" class in 4x, but if you try the same in
4x with "Event" you'll see that parent.Event.location.href="..." won't work
either. I don't feel comfortable with changing the order in which we resolve
names in the DOM code to make parent.Text in this case resolve to the frame
named "Text" since that would cause inconsisutencies in the DOM's behavior
depending on frame names on pages. Not good. (Brendan, holler if you disagree)

Over to evangelism, this site needs to use a non-reserved name for their frame
if they want to access it by name.

Comment 11

[Brendan Eich [:brendan]]

I would think, for backward compatibility, that we'd lazily resolve frames
before late-model DOM level N (N > 0) constructors.  Why would that order be
harmful?

/be

Comment 12

[Johnny Stenback (:jst)]

The order would be harmful because we rely on the order internally when setting
up the prototype chain of DOM objects. We could however reorder our code to not
rely on the window object's resolve order when setting up the proto's, and
you're probably right in that it's worth doing for backwards compatibility's
sake (although this is the only known case where it matters so far).

Taking bug again.

Comment 13

[Johnny Stenback (:jst)]

Pushing to mozilla1.0

Comment 14

[scottputterman]

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword.  Please send any
questions or feedback about this to [e-mail].  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.

Comment 15

[Brendan Eich [:brendan]]

4xp, but not as severe as other 4xp bugs.  jst, please advise on whether this
should hold mozilla1.0.

/be

Comment 16

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 17

[thebeastwitheyesthatstared]

this is still an issue with the above URL, as far as I can see.

Comment 18

[Fabian Guisset]

This was fixed some time ago in bug 222191. Marking as dup.

*** This bug has been marked as a duplicate of 222191 ***