In mailnews, we currently can't scroll through messages in the message pane of the mail app because of a scrolling bug (scrolling turns the screen blank...) in a window where the window's height is based as a percentage instad of a fixed value. For instance: In mailnews, we are using html frames to divide up the thread and message panes. We are then associating an iframe with each frame. So we a XUL file for the messagePane which looks like the following: <?xml version="1.0"?> <?xml-stylesheet href="xul.css" type="text/css"?> <!DOCTYPE window> <window xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:rdf="http://www.w3.org/TR/WD-rdf-syntax#" xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"> <html:iframe src="message.html" name="browser.webwindow" width="100%" height="100%" > </html:iframe> </window> With this type of configuration, we can't scroll within the message pane (which is an iframe). If the height is changed from 100% to a fixed value such s 440px (which is how navigator.xul currently works) then you are able to scroll fine, but you can't resize the message window because you are forcing it to be a fixed height. This makes it very hard to read mail messages in the message window. I'm not sure who on xp toolkit to assign this to so I'm going to start with Peter.

Can this be fixed for the dogfood milestone since we can't scroll to read mail messages in the message pane?

Have you tried this in an HTML or straight XML file? There's nothing XUL- specific about what you're doing. Assigning to hyatt as p2 for M3 to rule out XUL processing problems & reassign as needed. set QA Contact to beppe.

This is not XUL-specific. iframes in HTML have trouble with percentage heights. This should be re-assigned to Kipp or Troy.

assigning Greg as QA contact

reassigning to kipp, per hyatt's comment.

I have a "temporary" work around to which I can add to the message pane xul file to remove the height expression in terms of a percent. This will make it easier for QA to test mail related functionality. I can force the message pane to have a fixed height. The con is that resizing can't be done because the height is fixed and when the window is smaller than the height of the message pane, you can get two scroll bars (one for the message content and another for the iframe). I'd like to get permission to check the work around in. I've already been making the change for several Mail/News QA people in order to allow them to scroll through messages. The change would be to messagePane.xul, changing the height of the iframe from 100% to a fixed value --> 350px. Adding choffman to the cc list to ask for permission for the temporary work around. (Note: this is not a fix for this bug though...)

I have a "temporary" work around to which I can add to the message pane xul file to remove the height expression in terms of a percent. This will make it easier for QA to test mail related functionality. I can force the message pane to have a fixed height. The con is that resizing can't be done because the height is fixed and when the window is smaller than the height of the message pane, you can get two scroll bars (one for the message content and another for the iframe). I'd like to get permission to check the work around in. I've already been making the change for several Mail/News QA people in order to allow them to scroll through messages. The change would be to messagePane.xul, changing the height of the iframe from 100% to a fixed value --> 350px. Adding chofmann to the cc list to ask for permission for the temporary work around. (Note: this is not a fix for this bug though...)

I think the temporary workaround offerred by mscott is a good idea if the "real bug fix" cannot be done by M3 for dogfood mail.

There is already a bug filed for the iframe percent issue; use this to track the operational issue in mail&news...

Verified mscott's temporary fix works in the Mar171342 Win32 build of mail. Leaving this bug open for the "real" fix. Greg - what is the bug number for the iframe percent problem that you have? Then, this bug will probably end up being a dup of that one.

If this bug does end up getting assigned as a dup of the other one, let's keep an eye on the priority. I don't know what the other bug is targeted as. This is a pretty big eye sore on the mailnews client. Our message pane is pretty messed up without it.

See bug# http://bugzilla.mozilla.org/show_bug.cgi?id=3624

Umm can we talk about the milestone target date for this bug. AS I mentioned in the earlier bug comment, this is a really big stopper bug for mailnews. It was considered an M3 stopper how did it suddenly get bumped from M3 to M6? Can we talk about the rational behind an M6 target fix? I thought if we decided not to hold M3 for it that at the very least it would go into the M4 bucket.

For the height=% for iframe issue: CSS indicates that a percentage height will be based on the containing blocks height; if the containing block height is undefined then a value of "auto" is used. So unless the parent of the iframe is itself a fixed height, you will get a 200 pixel high iframe (as hard coded into the iframe source code). If you want your iframe to stretch to use up all the available space then make sure the parent is fixed size. This may not give you the layout you want, but its the best that CSS+HTML can do; there is going to be a meeting (this week in theory) to talk about how to fixup the navigator.xul layout with some kind of extension - either a new layout class or an extension to HTML layout. Since there seems to be a scrolling bug here too (in the initial part of the bug report) I'm reassigning to troy to look into that.

As Kipp said, a percentage based height is treated like 'auto' if the containing block height depends on its content height, i.e., it's not completely set. That's CSS2 I don't follow the detail of the scrolling problem Kipp mentions. If there is one, please open a new bug with a simple HTML example that demonstrates the problem

mscott? Is your temporary workaround still needed? Is there still a bug here?

Unfortunately bug 3624 was verified as fixed for the crash only, but a new bug was suppose to be opened by glynn for the scroll bar weirdness. Can't find one and he's no longer here. So this bug 3790 should be reopened and reassigned to mscott asking him to back out his temporary fix so we can test to see if the scenario in bug 6735 is fixed and to see if the original problem in this bug is gone.

Update: per conversation with alecf, his fix for 6735 basically ignores the temporary fix (which is a secondary fixed size window) that mscott put in for this bug. So this can be considered backed out and the original problem in this bug (scrolling causes the window to go blank) can verified with the 6/8 build.

So, mscott/lchiang...should this bug be marked Resolved/Fixed and Verified by QA now?

OK, using builds 19990609 on Win32, linux & mac the scroll bars work in all cases mentioned here and in other mailnews scroll bar bugs. Changing this back to invalid per Troys comments and marking verified because the scenario is working now.

BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL. XUL component will be deleted.