Closed
Bug 16218
Opened 25 years ago
Closed 25 years ago
Frames not acting in accordance with HTML 4.0 specs
Categories
(Core :: Layout: Images, Video, and HTML Frames, defect, P3)
Core
Layout: Images, Video, and HTML Frames
Tracking
()
VERIFIED
FIXED
M13
People
(Reporter: kvandyke, Assigned: pollmann)
References
()
Details
(Whiteboard: [HAVE FIX])
According to the HTML 4.0 specs at
http://www.w3.org/TR/REC-html40/present/frames.html#edef-FRAME , a <FRAME>
element that is not supplied with an explicit SRC="someurl" attribute should
then take on a default value supplied by the user-agent. Whatever value Mozilla
(and consequently, Netscape 4.x as well) supplies it with, it breaks the
frame layout when trying to use Javascript to set the HREF locations of specific
frames. The supplied URL demonstrates this. Notice in the source code that the
frameset specifies a border value of 2 and that no border is displayed. When the
user clicks on the word "Test" in the left frame, the two right frames are
supposed to load up with new URL's, but it doesn't happen.
Paying a visit to http://www.cs.fsu.edu/~vandyke/mozbug/index2.html will show
how the page is supposed to work. On this page, a SRC attribute is supplied and
the page renders and acts the way that it should when the link on the left is
clicked.
Updated•25 years ago
|
Assignee: karnaze → pollmann
Comment 1•25 years ago
|
||
Reassigning to Eric.
Some clarification:
Basically when you don't specify a SRC attribute of a FRAME tag the frame should
load up with something like a blank page. You should then be able to use
Javascript to assign a URL to that blank frame and the page should load up.
Right now Netscape 4.x nor Mozilla work correctly. It generates an error that
the frame does not have any properties and therefore it cannot assign a URL to
the frame.href property.
Assignee | ||
Comment 3•25 years ago
|
||
I think this might be due to an optimization in nsHTMLFrameInnerFrame that
prevents us from crating a webshell (needed to load a document) if the frame's
src attribute is null. I'll remove this optimization and see if that fixes the
problem.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
OS: Windows NT → All
Hardware: PC → All
Target Milestone: M13
Updated•25 years ago
|
Whiteboard: [HAVE FIX]
Comment 4•25 years ago
|
||
Marking [HAVE FIX].
Assignee | ||
Comment 5•25 years ago
|
||
Yup, that worked. Will check in for M13
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 6•25 years ago
|
||
Fix checked in. To verify, go to this URL:
http://www.cs.fsu.edu/~vandyke/mozbug/index.html
Click on the word Test. You should see two frames to the right load documents
in them. If the test fails, the page comes up with the right half white and
clicking on the word Test has no effect. Thanks!
FYI, I made the test simpler by making only two frames on the whole page: A
frame on the left which holds the Test link and a blank frame on the right.
Clicking on the link in the left should open only one page on the right of the
screen now.
Also, using build 2000010608 on NT4 with SP5 the page still does not open on the
right of the screen. Has this been added to the nightly builds or will it only
appear when M13 is released?
Assignee | ||
Comment 8•25 years ago
|
||
It will be in the morning builds starting the morning after I checked it in.
That means that it will be in 2000010708 or whatever the next build is. Thanks!
Updated•7 years ago
|
Product: Core → Core Graveyard
Updated•7 years ago
|
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in
before you can comment on or make changes to this bug.
Description
•