From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; N; Linux 2.2.12-20 i586; en-US; m14) BuildID: 2000030913 If the name of a frame is "content" and a page use: parent.content.location = ..... to change the url within a frame, the resulting frame will be displayed in "_top" instead of "content" I am not sure if this is a bug or just the problem of the site. The above works for Netscape 4.x and I couldn't find anything about "content" being a reserved word or name of a property. Reproducible: Always Steps to Reproduce: 1.Open test case 2.Select an item in the combo box in the right frame. Actual Results: hello.html displayed in "_top". Expected Results: hello.html should display in the right frame.

Oops... dunno how to attach multiple files that are linked.... I'll post a url to the test case instead: http://leeal.myip.org/mozilla/bug31378/index.html

Does behave differently than on 4.7. -> DOM0

The reason this testcase doesn't work as expected is that the name of the a frame in the frameset is "content" and that conflicts with the new navigator.content property (which happends to be the "_top" window). Same problem occures with frames named "menubar" (on www.freedrive.com, bug 30226) and probably others. Vidur says that these properties are new and we still have the option of renaming them to avoid name conflicts like these. Passing over to danm@netscape.com.

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

Forgive me for not checking this out myself (it's late and I'm aching to be out of here). But jst's comment above makes the problem seem very clear. (Thanks for looking into this!) Mozilla has added a couple of new internal-use properties to the window object. "content" is one of them. That's a compatibility problem, of course. Vidur has adjusted these new properties to be mutable -- you can subsume their Mozilla meaning by one of your own if you like (see bug 27775). In short, this should work, now that that bug has been fixed.

Unfortunately, this does not work. Testcase still opens file in window instead of in frame.

curses

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

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

(same as bug 33650)

nominating for nsbeta2

[nsbeta2+] will take fix by 6/1

Mass moving all dated nsbeta2+ bugs to M19

Updating from [6/1] to [6/15]

Cleaning up status whiteboard by marking beta2 minus (6/15 has passed) People or too doomed to handle this for beta2 Considering the number of dups of this bug, I'm nominating for beta3

Had a lot of trouble loading this page: timeouts and missing plugins and whatnot. But the problem this bug complains about, the failure to recognize a frame named "content," fell out of the fix for bug 33650.

seems that the bug is still occuring with build 2000062116. Please use this page for test case instead of the URL above: http://leeal.myip.org/mozilla/bug31378/index.html

Verified with 2000-07-05-09.