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)

Product:
Core
Component:
Layout: Images, Video, and HTML Frames
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: Erich.Iseli, Assigned: petitta)

References

(
URL
)

Details

Attachments

(2 files)

testcase where it doesn't work
331 bytes, text/html
Details
testcase where it works
435 bytes, text/html
Details 
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)

    
    

    
  


  

    
    

    
  
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.

    
    

    
  
CC'ing Harish - this seems like it might be happening in the parser.  Shouldn't
this testcase be using <NOFRAMES> ?

    
    

    
  
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 ;-)

    
    

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

    
    

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

    
    

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

    
    

    
  
QA Contact update
QA Contact: petersen → amar

    
    

    
  
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

    
  
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.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: