Frames don't display in quirks mode when some displayable element is shown in the frameset

RESOLVED WORKSFORME

Status

()

P3
normal
RESOLVED WORKSFORME
18 years ago
2 months ago

People

(Reporter: Erich.Iseli, Assigned: petitta)

Tracking

Trunk
Future
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

18 years ago
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

18 years ago
Created attachment 18913 [details]
testcase where it doesn't work
(Reporter)

Comment 2

18 years ago
Created attachment 18914 [details]
testcase where it works
(Reporter)

Comment 3

18 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

18 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

18 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.

Comment 6

18 years ago
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

18 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>.
(Reporter)

Comment 8

18 years ago
*** Bug 59725 has been marked as a duplicate of this bug. ***

Comment 9

18 years ago
reassigning to evangelism
Assignee: pollmann → petitta
Target Milestone: --- → Future

Comment 10

18 years ago
QA Contact update
QA Contact: petersen → amar
(Reporter)

Comment 11

17 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
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Updated

2 months ago
Product: Core → Core Graveyard
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.