Closed Bug 333994 Opened 18 years ago Closed 15 years ago

Firefox uses signed 16 bit integer for IFRAME height (Content is clipped - not rendered/shown beyond 32767px) [32768]

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect)

Product:
Core
Component:
Layout: Images, Video, and HTML Frames
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: luciolep, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(1 file, 3 obsolete files)

Minimal testcase: signed integers used for iframe height (and width?)
1.07 KB, text/html
Details 
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; fr) AppleWebKit/417.9 (KHTML, like Gecko) Safari/417.8
Build Identifier: Iframe max height of 32767 pixels !

Master page :
master.html
<html>
<head></head>
<body>
	<iframe id="anId" name="aName" width="100%" height="32768px" src="child.html" scrolling="no" frameborder="0"></iframe>
</body>
</html>

Child page (note: write 11000 lines into <body></body>, thanks copy/paste ;) ) :
child.html
<html>
<head></head>
<body>
line 1<br/>
line 2<br/>
....
line 11000<br/>
</body>
</html>

When you load master.html ( child.html must be into the same directory ), the content iframe is blast
However, with a 32767px height, the content will be shown. Sometimes it will freeze after be displayed


Somebody have an Idea ?

Thanks 





Reproducible: Always

Actual Results:  
The content iframe is blast


When the iframe is into a DIV, the iframe height is 100% and the DIV height is increased to 32768 ( in Javascript ) the problem is identical.
Attached file master.html (obsolete) — 
the file to launch
Attached file child.html (obsolete) — 

    
    

    
  

      
      
      
      

        Attached file
          
        master.html (obsolete)
        — 
      

    


  
the file to launch

        Attachment #218423 -
        Attachment is obsolete: true

    
    

    
  
See also bug 334405, "iframe about 32768px (2^15 px) from top of page makes Firefox stop painting"

    
    

    
  
I put a testcase here too: http://www.bazon.net/bugs/iframe-bug.html

There's an IFRAME embedded in a DIV.  After the IFRAME content was loaded, the IFRAME is resized to sufficient dimensions to display the full content without scroll-bars; the final size is alert()-ed.  The scroll mechanism is provided by the parent DIV.  If you scroll down around line 2183, you will notice that anything after it is blank (exceeds 32768 pixels).

This happens in Firefox/Windows; works fine with Firefox/Linux.  I haven't tested on the Mac.

This bug can seriously affect Zimbra (messages that display on more than 32768 pixels will look like that).  Any fix planned?

    
    

    
  
Confirmed on OS X 10.4.9. 

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a3) Gecko/20070322 GranParadiso/3.0a3

    
  
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE

    
    

    
  


  
I reopen this bug because it's not exactly a duplicate of Bug 215055, as I wrote in Bug 440879 Comment 4:

  See the attached testcase: Bug 215055 is about elements with 
  overflow!=visible. Furthermore for iframes seems Fx uses signed integers, 
  while for divs it uses unsigned. So a part of this bug seems simple to fix. 
  The other part (iframe can't be taller than 16 bit) is probably related to 
  Bug 215055.

        Attachment #218424 -
        Attachment is obsolete: true

        Attachment #218426 -
        Attachment is obsolete: true
Severity: critical → normal
Status: RESOLVED → UNCONFIRMED
Component: General → Layout: HTML Frames
Depends on: big-long-large-32767
Flags: blocking1.9.0.2?
Keywords: testcase
OS: Mac OS X → All
Product: Firefox → Core
Resolution: DUPLICATE → ---
Summary: The content of an iframe disappear when its height exceed 32767 pixels → Firefox uses signed 16 bit integer for IFRAME height (Content is clipped - not rendered/shown beyond 32767px) [32768]
Version: unspecified → Trunk
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: general → layout.html-frames

    
    

    
  
Not a blocker for security releases, if there's a trunk fix we can evaluate it for shipping on the stable branches after that.
Flags: blocking1.9.0.2? → wanted1.9.0.x?

    
    

    
  
Actually, this not really wanted. If you want it fixed, we should get it in 1.9.1 or 1.9.2.
Flags: wanted1.9.0.x? → wanted1.9.0.x-

    
    

    
  
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090722 Minefield/3.6a1pre

Fixed by bug 352093 in 1.9.2 trunk (not in Fx 3.5.x).
Used testcase of bug 503941 to verify this.
Status: NEW → RESOLVED
Closed: 17 years ago → 15 years ago
Resolution: --- → FIXED

    
  
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: