Closed Bug 6886 Opened 25 years ago Closed 25 years ago

innerHeight and outerHeight wrong for iframes

Categories

(Core :: Layout, defect, P1)

Other
All
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: slamm, Assigned: nisheeth_mozilla)

References

Details

Attachments

(1 file)

frame innerHeight and outerHeight are set to the same value as the entire window.
Attached file Test case (will not work in Nav 4x) (deleted) —
Priority: P3 → P1
Changing priority to P1.
The test case I attached also depends on bug #3338.
Blocks: 7403
No longer blocks: 7403
Blocks: 7403
Blocks: 7996
No longer blocks: 7403
Blocks: 7998
Assignee: joki → nisheeth
Summary: window props: innerHeight and outerHeight wrong for frames → innerHeight and outerHeight wrong for iframes
nisheeth, would you take a look at this? (Or, pass it on to the right person.)
Status: NEW → ASSIGNED
Target Milestone: M9
Here's the problem. GlobalWindowImpl::GetInnerHeight() in dom/src/base/nsGlobalWindow.cpp gets the inner height of top level windows as well as child (i)frames. This function equates the innner height to the height of the container of the root webshell. This is OK for a top level window but wrong for a child (i)frame window. The inner height for the latter case should be the height of the window contained by the child (i)frame's webshell. CCing Vidur. How do I figure out inside GlobalWindowImpl::GetInnerHeight() that the inner height of an (i)frame is being requested? Accepting bug and setting target milestone to M9.
I looked up CVS blame and saw that GetInnerHeight() was added by Tom. CCing him. Tom, can you shed some light on the issue? Thanks.
So in looking at this code again its seems to me that we might be able to have innerWidth/Height just always use the size of the associated webshell. However, varying behavior based on whether you were in a frame or not would still be necessary for outerWidth/Height so we still have to solve this. I'm betting we can just check whether we, the js window, has a parent. If so then we're a frame and we use webshell bounds, otherwise do what we do now and use browserwindow bounds.
But, won't top level windows opened from scripts also have a parent set?
No. They have a webshell parent (chrome stuff) but not a js parent. The chrome is hidden from them
So, this is fixed so that the inner width and inner height of (i)frames get calculated properly. I need to next look at how 4.x's calculates outer width and outer height for (i)frames. For now, the outer width/height are the same as inner width/height for (i)frames. If 4.x compensates adds in the frame border for the outer width/height, we need to do the same in 5.0. I'll update this bug with what I find.
The way I understand it, innerHeight is the height of the content and outerHeight is the height of the view. The innerHeight will be larger than the outerHeight if the content spills outside of the view area. The innerHeight is what I want to know because that will tell me how big an iframe needs to be so that all the content is visible without a scrollbar.
Actually that's not the difference between innerHeight and outerHeight. innerHeight is the size of the content area of the window, outerHeight is the full size of the window, including chrome. We did in 4.x also reflect document.width and document.height which was the size of the content itself so I guess that's what you're looking for. Those aren't yet hooked up in Gecko, I have a bug for it somewhere.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
I checked out 4.x. The outerWidth and outerHeight properties on frames return the width and height of the entire browser window including chrome. I've changed the getters of these two properties in nsGlobalWindow.cpp and checked my changes in. Marking this bug fixed.
Status: RESOLVED → VERIFIED
Based on nisheet's comments, marking as verified fixed in the July 30th build.
No longer blocks: 7998
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: