108591 - Gecko return the wrong height from the Iframe first time.

Status: VERIFIED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[Carrie Peng]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
BuildID:    2001110103

Use the test program I attached to bug 106105, if you look at the height print 
out, the first time the height returned is alway larger than the rest of time. 
This cause our dialog alway come up too tall the first time. The rest of time 
is OK.

Reproducible: Always
Steps to Reproduce:
1.Download the attached test program from bug report for 106105
2.Click on the button, observe the print out height value
3.Click on the button again, observe the print out height value.
4.Repeat 3.

Actual Results:  The height value returned from step 2 and 4 is different even 
though they point to the same IFrame with the same content. 

Expected Results:  The value returned from step 2 and 4 should be the same

Comment 1

[Boris Zbarsky [:bzbarsky]]

dom0

Comment 2

[Milton C. Soong]

This bug is linked to Vantive Bug#262229, and must be fixed by CS Gecko zero bug 
build date on 1/14.

Comment 3

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Nominating to get this on the radar...

Comment 4

[Johnny Stenback (:jst)]

Ok, after quite some time of looking into this I realized what the "problem" is,
and I don't think we want to fix this in mozilla.

The "problem" that's seen here is related to the scrollbar handling in mozilla,
the root of the problem is that if a scrollable view's (i.e. the iframe in this
case) height is less than a certain limit (~30px or so) mozilla doesn't show the
scrollbars at all, i.e. if there's not enough room to show the scrollbars,
mozilla doesn't show them since they won't fit. This kinda makes sense. The
weird behavior shown in the testcase in bug 106105 (I'll attach a slightly
modified version of the testcase to this bug) is not that the height information
is incorrect the first time, it's actually correct the first time, and incorrect
the rest of the time. Or so it seems, given the scrollbar behavior described
above, it's always correct.

Because of the above, here's what happens when you load the testcase that I'm
about to attach:

The page loads, the iframe is ~150px high. You click on the "change content"
button and mozilla shows the long text in the iframe and given that the text
doesn't fit in the iframe, mozilla puts in the scrollbars. The reported height
is now 304px, which is correct. The code then sets the height of the iframe to
304px.

Now if you press the "change content" button again, we replace the long text in
the iframe with the short text, which happens to fit on one line, the reported
height of the content in the iframe is now 19px. We set the height of the iframe
to 19px, which shrinks the iframe down to 19px high. 19px is not high enough to
show the scrollbars in, even if they're needed (which they happen to be even
with just one line of text because of margins/paddings).

If you after this click on "change content" a third time, mozilla will replace
the short text in the iframe with the long text, the content of the iframe is
reflown and the iframe will show the whole text. But since the iframe is still
only 19px high (not high enough to show the scrollbars) the text is layed out in
the whole iframe area (excluding scrollbars), this causes the content of the
iframe to be *wider* than in the first case where the long text was shown in the
iframe. Because of this, more text fits on every line, and we end up needing
fewer lines to show the whole text, thus the height of the content in the iframe
is not 304px, like it was in the first case, it's now only 285px (which happens
to be 304-19px, i.e. one line less than before).

This "problem" (which isn't really a problem) can be worked around in the code
that deals with iframes that are too low for scrollbars to show up, and thus I'm
marking this bug as INVALID.

If someone has ideas on how to better deal with scrollbars in scrollable views
that are not large enough to show the scrollbars, please file a new bug on the
scroll code (XPApps: GUI Features, or some such component).

INVALID.

Comment 5

[Johnny Stenback (:jst)]

Attachment: Testcase showing this "problem"

Comment 6

[Carrie Peng]

This is not entirely true. May be my test case is not good enough. So I updated 
it. This time, I make the iFrame load the long text when it first come up
(scroll bar show). Then click on the change content button. It will display the 
same content. Notice when the alert come up, the scroll bar is not there, the 
height is 285. Then click button again, it show the height for short text is 
76, not scrollbar when alert show. press button again, notice the scroll bar is 
still there but the height is 304 (at which time the content is the same as the 
285 height content.

Comment 7

[Carrie Peng]

Attachment: Change the program to initially load the long text. Made the short text longer

Comment 8

[Judson Valeski]

re-opening bug.

Comment 9

[Johnny Stenback (:jst)]

I can't see that the new testcase shows any bugs with how we report the height
of a document either, it's just a different variation of the same problem, but
this time unrelated to the lack of scrollbars in small scrollable views.

Here's what happens:

You load the testcase, the iframe starts out being the same default height,
~150px. From the onload handler the long text is written into the iframe and
that text is too long to fit in the 150px iframe, so we create scrollbars. The
height of the content in the iframe is now 304px and the height of the iframe is
then set to 304px (which still requires scrollbars due to the margins n' all that).

Now, the iframe contains the long text, with the scrollbars showing, the height
of the content (w/o the margins) is 304px, the height of the iframe is 304px.
Then you click on "change content", the long text is re-written into the iframe,
which means we throw away everything in the iframe and start feeding it data,
and we can write the whole long text into the 304px high iframe w/o having the
scrollbars show up, then the alert pops up and says the height of the content is
285px (since there are no scrollbars). Once you close the alert the code sets
the height of the iframe to 285px, which is not enough to contain the content
w/o showing the scrollbars, we reflow, rewrap the text and the scrollbars show up.

There's arguably one bug here in how mozilla handles scrollbars. If you look at
the initial state of this page (after the onload has fired), the iframe is 304px
high, which is enough to show the text w/o scrollbars, but we show the scollbars
anyway. This happens because we start out with the long text in a 150px high
iframe where the scrollbars are needed, then we enlarge the iframe to a value
that happens to be large enough to fit the text w/o the need of scrollbars, but
because the scrollbars are already there, we don't remove them since doing that
would require a lot more reflowing on window resize which would slow things down
significantly. If you want to, go ahead and file a separate bug in this problem,
but it's not easy to fix w/o unacceptable slowdowns, so don't expect it to be
fixed quickly.

You can work around this issue in the JS that exposes this behavior by initially
setting the iframe to be large enough for the content to fit in the iframe w/o
the need for scrollbars, then you measure the size of the content and set the
size of the iframe to be the size of the content plus enough space for margins
and padding to have room too. If you do this, you'll run into a related bug that
I found while looking into this problem, see bug 115352, but you can work around
that too in your JS.

I'll attach a new testcase that works around the scrollbar issue, but I'm
marking this bug INVALID again since there's no problem with measuring the
height of iframes.

Comment 10

[Johnny Stenback (:jst)]

Attachment: Testcase that works around the scrollbar issue and explain what the workarounds are.

Comment 11

[Carrie Peng]

Let me first explain what bug I try to fix. We have a iframe that will contain 
a Calendar. But when it come up, we do not want any scroll bar show up. Depend 
on which month the user looking at, the length of the content of the iframe 
(Calendar) can change. In this case, because the inconsistency of showing the 
scroll bar when you do the content height calculation, it cause scroll bar show 
up in our calendar. I can only create the test case to the best I understand 
the problem(to me I saw the number return is not consistant). The bug you 
mentioned is actually the one we try to fix. Since you mentioned to fix this 
bug will take long time. I guess our team need to figure out what to do next.

Comment 12

[Judson Valeski]

minusing due to workaround and INVALID status.

Comment 13

[Michael Dunn]

Bugscape:
http://bugscape.mcom.com/show_bug.cgi?id=11498

Comment 14

[Jennifer Kobayashi]

Marking verified, see bugscape bug 11498 for more information.