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

RESOLVED FIXED

Status

()

Core
Layout: HTML Frames
RESOLVED FIXED
11 years ago
7 years ago

People

(Reporter: Alex, Unassigned)

Tracking

({testcase})

Trunk
testcase
Points:
---
Bug Flags:
wanted1.9.0.x -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

11 years ago
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.
(Reporter)

Comment 1

11 years ago
Created attachment 218423 [details]
master.html

the file to launch
(Reporter)

Comment 2

11 years ago
Created attachment 218424 [details]
child.html
(Reporter)

Comment 3

11 years ago
Created attachment 218426 [details]
master.html

the file to launch
Attachment #218423 - Attachment is obsolete: true

Comment 4

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

Comment 5

11 years ago
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?

Comment 6

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

Updated

10 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 215055
Created attachment 334317 [details]
Minimal testcase: signed integers used for iframe height (and width?)

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: 215055
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
Duplicate of this bug: 440879
Duplicate of this bug: 403759
Duplicate of this bug: 384614
Duplicate of this bug: 397462
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-
Duplicate of this bug: 503941

Comment 16

8 years ago
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
Last Resolved: 10 years ago8 years ago
Resolution: --- → FIXED
Duplicate of this bug: 564836
You need to log in before you can comment on or make changes to this bug.