Closed
Bug 59443
Opened 24 years ago
Closed 23 years ago
Frames don't display in quirks mode when some displayable element is shown in the frameset
Categories
(Core :: Layout: Images, Video, and HTML Frames, defect, P3)
Core
Layout: Images, Video, and HTML Frames
Tracking
()
RESOLVED
WORKSFORME
Future
People
(Reporter: Erich.Iseli, Assigned: petitta)
References
()
Details
Attachments
(2 files)
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001105
BuildID: 2000110520
Frames don't display in quirks mode when some displayable element is shown in
the frameset.
Reproducible: Always
Steps to Reproduce:
If you are registered with etour:
1. enter your e-mail address and press button "start touring"
2. a frameset loads with a navigation at the buttom and a random page at the top...
Actual Results: ... but nothing except the title is shown
Expected Results: display frames correctly
This happens only in nav quirks mode. if you set an explicit DTD, everything
shows ok. (see testcases)
|
Reporter | |
Comment 1•24 years ago
|
||
|
|
Reporter | |
Comment 2•24 years ago
|
||
|
|
Reporter | |
Comment 3•24 years ago
|
||
Comments on the testcases:
The difference between the first and the second testcase is that the first has
no doctype declaration (and therefore uses quirks mode) whereas the second one
has a transitional doctype declaration.
Even if we have an input type="hidden", I call it a displayable element, because
if you replace the type with text or whatever, we have the same situation. You
could as well add anything else there.
If you remove the input field and keep only the form start and end tags, the
problem disappears.
|
||
Comment 4•24 years ago
|
||
CC'ing Harish - this seems like it might be happening in the parser. Shouldn't
this testcase be using <NOFRAMES> ?
|
|
Reporter | |
Comment 5•24 years ago
|
||
Eric Pollman, as I didn't write the etour site, I have no influence on how it is
written. But as this hidden field is used by the program when the frames are
shown, then I think it shouldn't be in the <noframe> part. However, I think the
best solution for this would be to assign the variable with javascript instead
of a hidden input field.
Pollmann, the only difference that I see between the working and non working
testcases is the DOCTYPE. And parser does not do anything different based on
DOCTYPE. In other words it's the same DTD ( CNavDTD ) that would get triggered
for both testcases. IMO, this is a layout issue ( since the *layout* mode
changes with DOCTYPE ). But, will anyway take a look into it to see if parser is
involoved at all ;-)
|
|
||
Comment 7•24 years ago
|
||
Doh, I meant to attach a dump of the doctype model that I got when looking at
this page - there wasn't a frameset because a <FORM><INPUT></FORM> appeared
before the <FRAMESET> and that opened up a <BODY>.
|
||
Comment 9•24 years ago
|
||
reassigning to evangelism
Assignee: pollmann → petitta
Target Milestone: --- → Future
|
|
Reporter | |
Comment 11•23 years ago
|
||
This appears to work now in the 0.9.4 milestone. E-Tour site has been redesigned
in the meantime.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
|
||
Updated•6 years ago
|
Product: Core → Core Graveyard
|
||
Updated•6 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
•