Closed Bug 307821 Opened 19 years ago Closed 19 years ago

Frameset handling broken, child pages can display as blank

Categories

(Core :: DOM: HTML Parser, defect)

Product:
Core
Component:
DOM: HTML Parser
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: jon, Assigned: mrbkap)

References

(
URL
)

Details

(Keywords: regression, testcase)

Attachments

(2 files, 1 obsolete file)

testcase
120 bytes, text/html
Details
Fix even more cases
8.79 KB, patch
jst
: review+
jst
: superreview+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050908 SeaMonkey/1.1a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050909 Firefox/1.6a1 ID:2005090917

Here is probably as simple a frames page as one can have, reducing the Awstats
page yet still showing the rendering issue:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
   "http://www.w3.org/TR/html4/frameset.dtd">
<HTML>
<HEAD>
<TITLE>A frameset document</TITLE>
</HEAD>
<FRAMESET cols="50%,50%">
  <FRAME src="http://www.google.com/">
  <FRAME src="http://www.google.com/">
</FRAMESET>
</HTML>

The above will appear to load all the content, including the frame's "src"
pages, yet the frame elements will only render as blank.

The same issue also occurs should frame rows be used instead of cols. Curiously
though, should it be a "complex" frameset with rows and cols, expected behaviour
occurs again, with correct rendering:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
   "http://www.w3.org/TR/html4/frameset.dtd">
<HTML>
<HEAD>
<TITLE>A frameset document</TITLE>
</HEAD>
<FRAMESET cols="50%,50%">
  <FRAMESET rows="*,200">
      <FRAME src="http://www.google.com/">
      <FRAME src="http://www.google.com/">
  </FRAMESET>
  <FRAME src="http://www.google.com/">
</FRAMESET>
</HTML>

All framesets worked correctly as of build:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050909
Firefox/1.6a1 ID:2005090903

... though appear to have broke after build:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050909
Firefox/1.6a1 ID:2005090916

Reproducible: Always

Steps to Reproduce:
1. Visit any page without nested frames, ie: all rows or all cols
2. "Child" elements of frameset (ie: frame), do not render and show up as blank
Actual Results:  
Pages don't render...

Expected Results:  
Render the child elements of frameset for "simple" framesets as it does with
"complex", nested framesets.

N/A
Attached file testcase — 

    
    

    
  
mrbkap, is this yours from bug 272702? DOMi says that the frames are children of
<head> rather than of the <frameset>.
Assignee: nobody → parser
Severity: normal → major
Status: UNCONFIRMED → NEW
Component: General → HTML: Parser
Ever confirmed: true
Keywords: regression, 
          
            testcase
Product: Firefox → Core
QA Contact: general → mrbkap
Version: unspecified → Trunk

    
    

    
  
Certainly sounds like it. I'll try to figure out what's going on ASAP.
Assignee: parser → mrbkap

    
  
Blocks: 272702
Status: NEW → ASSIGNED

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Framesets are bodies too! (obsolete)
        — 
          — Splinter Review
      

    


  
At least in terms of whether to put whitespace/userdefined tags in the head or
the "body" (not the head), framesets are equivilant to bodies.

        Attachment #195512 -
        Flags: superreview?(jst)

        Attachment #195512 -
        Flags: review?(jst)

    
    

    
  
Comment on attachment 195512 [details] [diff] [review]
Framesets are bodies too!

I really like to spam jst with these requests... This patch doesn't go quite
far enough for framesets, more comprehensive patch in a bit.

        Attachment #195512 -
        Attachment is obsolete: true

        Attachment #195512 -
        Flags: superreview?(jst)

        Attachment #195512 -
        Flags: review?(jst)

    
    

    
  


  
I noticed after I attached the last patch that we always wanted to use (_BODY |
_FRAMESET) in these sorts of tests. So I introduced a flag to indicate this.
This patch also fixes such gems as:
<framset>
  <style></style>
  <frame>
</frameset>

And
<frameset>
  <meta>
  <frame>
</frameset>

        Attachment #195514 -
        Flags: superreview?(jst)

        Attachment #195514 -
        Flags: review?(jst)

    
    

    
  
Comment on attachment 195514 [details] [diff] [review]
Fix even more cases

>+      if ((mFlags & NS_DTD_FLAG_HAS_MAIN_CONTAINER) ||
>+          mHeadContainerPosition == -1) {

This should test using &&. I've fixed it locally.

    
    

    
  
FWIW this bug exists on Linux builds too.

    
    

    
  
Comment on attachment 195514 [details] [diff] [review]
Fix even more cases

r+sr=jst

        Attachment #195514 -
        Flags: superreview?(jst)

        Attachment #195514 -
        Flags: superreview+

        Attachment #195514 -
        Flags: review?(jst)

        Attachment #195514 -
        Flags: review+

    
    

    
  
(In reply to comment #8)
> FWIW this bug exists on Linux builds too.

Just want to say that I experience the same problem in Camino as well...



    
    

    
  
Fix checked into the trunk.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
OS: Windows XP → All
Hardware: PC → All
Resolution: --- → FIXED

    
    

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

    
    

    
  
Heh, too bad Tp is back at ~910ms again ;-).

    
    

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

    
    

    
  
(In reply to comment #11)
> Fix checked into the trunk.

Confirm frames handling in both DOMi and visual inspection are fixed, tested in
build:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050910
Firefox/1.6a1 ID:2005091017

    
    

    
  
Verified FIXED using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1)
Gecko/20050910 Mozilla/1.0
Status: RESOLVED → VERIFIED

    
    

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

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: