72.29 KB, image/png
75.38 KB, image/png
71.59 KB, image/png
63.62 KB, image/png
77.70 KB, image/png
114.06 KB, image/png
40.84 KB, image/jpeg
Hi ! If I enlarge a long mail-header in preview-window, this window starts flickering. I suppose that this is caused by a very long mail-header - this prevents me to do anything else than watching the flickering :-) Only kill can fix this problem :-)) Regards Marc Schöchlin
related: bug 124658
I've also seen this behaviour when I expand the headers section. Unfortunately, it's a hard bug to reproduce. I suspect it shows up the first time I load the mail viewer. Note: To stop the flickering, I just need to reclick the disclosure triangle. I am using the RC1 release.
This or a similar problem with continuous MailNews preview UI resizes still exists in moz1.2.1 . I can only reproduce it on low resolution displays, in our case 800x600. The machines in question are X11 thin clients, making the problem even more obvious (since its slower) but I have reproduced it on a local display as well. I'll provide a detailed description next time I see this problem, I've been on holidays for 3 weeks.... It seems to be caused by very long /attachment names/ as well as headers. IMHO its a very big barrier to Mozilla's usability on lower resolution displays. Please confirm bug.
I've been able to reproduce this -- it seems that the fewer memory resources available, the more severe the problem. Full Desktop Environments (i.e. Gnome, KDE) seem to produce this more accurately than lighter WM's. Unfortunately, it's not 100% reproducable on my system, and may not be a Mozilla bug at all...
A great way to observe problems like this is to install LTSP and a second NIC, then run moz remotely on a 486 with 16mb of RAM. You get to see all the draws, flickers, redraws, rearrangements, etc quite nicely. We use P100 thin clients with 32mb of RAM here and mozilla is quite useable, but its very clear where there is inefficiency in the layout and redraw engine.
Is this a dupe of (or rather, superceded by) Bug 188138? Looks like it.
I was mistaken about the duplication of 188138; but I think it might be the same thing reported in bug 126129. Still present in 1.3Final? 1.4a? 1.4b nightly? I do not agree that this is a "critical" or even major bug; there is no data loss or crash, and it appears to be hard to duplicate. To clarify: I believe the original report is talking about "long header" in the sense that expanding the header pane pushes the vertical splitter upwards (see Bug 167468) which starts the horizontal splitter vibrating (similar to Bug 201379). (Marc, do you agree with that?) Comment 4 appears to be talking about long strings within a header, as discussed in bug 188138 (and which is pretty easy to duplicate). Craig, am I reading that right?
Re: #7 I observe the exact problem described in this bug on our client machines at work. However, yes I also see behaviour like that described in the bug you reference.
Also, I must disagree regarding the severity of the bug. IMHO its quite a serious problem for anybody who is encountering this problem. There is often data loss and/or a crash, since the user must frequently "killall mozilla-bin" before they can get things back in working order. You'll lose any messages you're composing, the state of your browser, etc. It is hard to duplicate intentionally, but I've done it accidentally a fair few times. Unfortunately, it hasn't happened yet when I can look into the problem more rather than killing mozilla and getting on with my work. Sorry for the spam.
Craig, you are right about the severity, I somehow missed that the program has to be killed externally when this occurs. Any thoughts on whether this bug duplicates bug 126129?
Could be. It looks related, but he seems to be very specific that its the number of messages / list length of the message list pane that causes the problem. He also hasn't mentioned any dividers moving, something that seems to come with the problem described in this bug (and my experience of it). I wouldn't think it a dupe, at least on the surface - header length and resulting positioning problems & effects, vs a message list bug. That said, I suspect I've seen both in action - hard to say. I'm not overly familiar with Mozilla's innards (yet! have to find /time/ first) so I can't comment on that side of things.
Confirming this bug due a lot of interest and its apparent relation to bug 201460. I'm willing to set a dependency for this bug on that one if any of the reporters agree. There is a patch available at that bug; if anyone interested in this one is able and willing to build with the patch and report whether it addresses this problem, that would be good.
*** Bug 126129 has been marked as a duplicate of this bug. ***
Would you please read Bug 210184, is this the same Bug? Thanks.
OK, I've done some screenshots. The jitter was slow enough that with a P133 LTSP client I was able to, after many repitions, capture some hopefully useful shots. This was a very inaccurate process, since the capture doesn't ocurr the moment one clicks to take the screenshot. In these screenshots I'm switching between the two messages you see highlighted. I start with the 'test' message selected, and then click on the one below it. The separator jumps around, first moving left (shrinking the mailbox area) then jumping back to it's original position. Nothing is achieved but a lot of wasted redrawing and uglyness. Interestingy, if I hide the mailbox area the problem does not ocurr. If I shrink the mailbox area below a certain size, it does not ocurr. It seems to be some issue where Mozilla tries to rearrange things to better fit the message on screen, but then changes everything back again. IMHO the dividers should be ABSOLUTELY FIXED unless the USER moves them, since things jumping around for any reason can be annoying. Anyway, I'll attach those PNGs now. They were taken at 800x600 screen resolution BTW - this issue appears to only ocurr in small mail windows. This bug is a MAJOR barrier to useability at low screen resolutions, especially on slower machines. Sometimes the jitter doesn't stop, either - whenever the user clicks in the attachments area or message body the whole thing gets redrawn, complete with mail pane rearrangement.
Created attachment 128141 [details] Mail window with initial message selected This is the mail window in a fairly normal state. Note the fairly long email address and the presence of the attachments area with a few files that have medium-length names.
Created attachment 128142 [details] mid-jump #1 The following screenshots are not from a single sequence - this wasn't possible. I repeated things quite a few times to get them. Anyway, I've moved to the message below the test, and as you can see the separator bar has been moved and is redrawing.
Created attachment 128143 [details] mid-jump #2 Similar to the previous - things are redrawing after the bar has jumped to the left, and jumped back to it's normal position.
Created attachment 128144 [details] separator bar pushed out to left by message OK, here's an interesting one. I managed to capture a screenshot of Mozilla when the separator had jumped to the left of the window (compressing the mail folders pane to a smaller size) but before it'd jumped back. Hope this tells you all what I'm on about!
Created attachment 128145 [details] Everything has settled down to a stable state here Jumping, jittering and repeated half-completed redraws are over. Everything has settled down to display the next message.
Created attachment 128146 [details] With this message it jittered 5+ times then stopped with the bar on the left. With this message, when I clicked on it the separator between the mailboxes and the rest of the window jumped back and forth 5+ times in rapid succession. While it settled down looking like this, with the separator displaced to the left of where it normally sits (where I put it!), the message will periodically jitter around again before returning to this state. Almost any interaction with the mail client window seems to cause this, ie clicking on the msg body, an attachment, the grey area displaying the headers, or the message in the message selection pane. It appears to be MOVING FOCUS between these things that causes the issue - or at least, if I click in the msg body it will jitter once, but further clicks in the msg body don't cause more jittering. If I click on (say) an attachment, it'll jitter, and it'll jitter again when I click back in the msg body. Weird, eh? Utterly infuriating to use, too. To reproduce, try sending yourself several messages with long email addrs, attachments, possibly long subjects, etc. Shrink the mozilla window to ~800x600 or smaller (though I've reproduced this at home on a 1600x1200 display it's not easy!) and click on one of the messages. Then click on a normal length one w/o attachments, or another large one. If things work as expected, it'll leap all over the place - though probably very rapidly if you're working on a local display on a fast-ish machine. Maybe this would fix it: disallow messages from changing the position of the separators, full stop. Force them to display only within the already allocated area framed off by the vertical and horizontal pane separators. I'm going to see how hard it is to do, but I've never even looked at the Moz code beyond messing with the DOM inspector, so don't expect miracles (or results, probably).
I just realised that the screenshots I did recently were using the gtk2 mozilla build. Just to confirm, the problem does exist under the default mozilla builds as well. It is easier to capture screenshots in the gtk2 build due to the slower redrawing. I've been able to cause this on up to 1280x960 displays using long attachment names, From: addresses and subjects. Any suggestions on what bits of code to start looking at - this is driving me nuts, so maybe I can help fix it. bug 201379 is vaguely related to this one, I think. The problem is still present in 1.4 final - I'm now testing 1.5a.
Craig Ringer: The three "specific issues" you mention in comment 24 are all described in bug 91662, but as 'static' layout issues. Are you seeing rapid, repeated redraws for those cases? Do those cases involve a situation where you need to "killall mozilla-bin" as you stated in comment 10? This bug, I thought, was about the sort of jittering/flickering seen in bug 201379 and bug 201460, where Mozilla repeatedly redraws itself (as in, lays out with a scrollbar, draws, decides the new layout doesn't need a scrollbar, re-lays out, redraws, decides the scrollbar is necessary after all, ...). Note that there is a patch pending in 201460 that you should integrate if you're making your own builds. If the problems you're attempting to fix are static, that is 91662, you'll make a lot of people happy if you can fix them.
I see the effects of bug 91662 regularly. It addresses some, but not all, of the issues I've seen here, so I'll post a reference to this bug there. Bug 91662 doesn't seem to cover repeated rapid redraws, however. As for needing to kill -9 mozilla due to the effects of bug 201460, that hasn't happened in a while. While unnecessary redraws are still very common, they don't seem to go into an infinite loop anymore. In fact, I rarely see the horizontal separator (between message list and message display pane) move at all now. Good! The less the browser rearranges the display, the better IMHO. When I see the scroll bar vanish (bug 91662), that is generally not accompanied by repeated redraws. However, when the actual message display pane pushes the vertical separator out to the left and reduces the size of the mailboxes area, that is usually accompanied by at least one, if not 3 or 5, redraws - all very rapidly. Sometimes when displaying a problematic message, tiny redraws, sort of a momentary repositioning of some elements, ocurr periodicaly (every few seconds) even when the user does nothing but move the mouse. I haven't yet traced a cause for this beyond "when the layout is already broken". 99% of cases are worked around by collapsing the mailbox pane, but that's not really a useful way to work. So, what this bug covers that the others do not is repeated, but not looping/infinite, movement of the vertical separator when messages are opened that have very long subjects, From: addresses, or medium length subject/from and attachments (especially long attachment names). Not only does it move the vertical separator (which IMHO it should not do, ever), but it does so repeatedly and frequently to no purpose. Especially, when /leaving/ a problematic message, the separator returns to it's normal position, jumps back to the left again, and finially returns to normal. Each movement is accompanied by redraws of many elements of the mailnews window contents. So, I see | | | | |----| | | | ( || | ||-------| || | | | | | |----| | | | ) repeats several times, stops on middle diagram if the message has long subject etc, or bottom diagram if I've just /left/ such a message and selected a more normal one. Even one level of threading seems to make this /much/ worse. Reading the original bug message, perhaps what I'm talking about is a different bug again. The original bug report appears to be talking about but 201379. *arrggh* This mess of layout & redraw problems is a bit nightmarish to sort out, isn't it? I have a few observations, from /use/ of mozilla mail, about the general nature of these layout/redraw issues. Having not yet had time to delve in the code, I can't back them up with anything and may be just wrong, but this is the percieved behavior: mozilla doesn't appear to have a "policy" for dealing with oversize objects ESPECIALLY strings. Instead of tuncating them (... termination or "blah blah ... blah"), and displaying a tooltip, wrapping them, or otherwise handling it, mozilla seems to "make space no matter what". When it does truncate strings, it seems to do so based on a hard-coded length limit, not something based on the amount of space actually available. This causes issues for lower-resolution displays and users of large fonts. Additionally, mozilla seems to consider a lot of elements OK to move around where, perhaps, it should not. Pane separators are a good example. While there are times that these need to move to display all the content, it seems I question if this should be happening automatically at all. Perhaps it's better to let the user arrange things and not mess with it? Certainly Mailnews is currently much too free with rearranging things message-to-message. These two issues - the tendancy to try to shove things around or just break layout rather than truncate strings, and the tendancy to shove separators around to make space, results in an annoyingly fluid and jumpy UI. At least, that's my impression and opinion. I hope I've at least clarified what I'm on about here.
Further information and initial basic workaround: The problem can be /significantly/ reduced by setting the attribute "flex=0" on the vbox element folderPaneBox ( a direct child element of messengerWindow ). I did it via the DOM inspector, and noticed an instant improvement. It does not eliminate the multiple redraws, but it's now much closer to the behaviour reported in bug 91662 . There is still extra redrawing that's just not needed, but it's nowhere near as bad. Is there any reason not to do this, at least for a private "low res screen" build? If there isn't, I'll be deploying a custom 1.4 build for our LTSP workstations soon, this makes a massive difference. All because I noticed a casual reference to "flex=0" in one of the other bugs :-) Craig Ringer
Could this be related to the flickering I get when clicking the "view" link at the bottom of http://www.xulplanet.com/tutorials/xultu/trees.html? If I resize the window that pops up even smaller, Firebird pegs the CPU at 100%. If I make it larger, the flickering stops.
I don't see any jitter, and I'm working at 800x600 (*ick*) now. Perhaps you're working under Windows with "large fonts" set or something? If I shrink the window, the beyond a certain amount, the contents don't cleanly scale but project over the edges - the elements appear to have minimum sizes. I cant't reproduce any flickering (Mozilla 1.4, RH9, gtk2/xft build - I'm @home so I'm not using the 'vanilla' mozilla I usually use for testing).
I'll check it on my home machine later. My work machine runs Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b; MultiZilla v188.8.131.52J) Gecko/20030728 Mozilla Firebird/0.6.1
Created attachment 129657 [details] CPU pegged at 100% due to redraws Check out the CPU time... it doesn't ever stop flickering. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030811 Mozilla Firebird/0.6.1+ (latest win32 firebird nightly)
Chris Thomas, your bug may be related but isn't this bug. Note that bug 201460 is sort of the clearing-house for rapid-redraw/flickering/jittering issues, which happen in a number of locations, so you might want to add your symptom to that bug, particularly if it's easily reproducible; when you report, please state your version and theme, if applicable. (With Moz1.4 Final, I don't see the Find File dialog flickering.) If you're up to building your own executable, there is a patch at that bug which may help. Craig, regarding your comment 26: I tend to agree that this bug originally was the same thing as bug 201379, and Marc has not commented here since I started paying attention to it. Since I've never seen these symptoms in Mozilla mail (not W2K, 1600x1200, large fonts, nor W98, 1280x768, small fonts), and have never run Linux, I've not marked this as a dupe; in particular, your comment 10 let this bug continue as New. If this bug does dupe 201379 (originally), and your current symptoms are largely 91662, I'd just as soon see this duped over. If there is something distinct that's still present here, it should stand, but the summary should be updated to indicate what that is (or a new bug should be opened to supercede this). I have no idea about the flex=0 change, but if it works, great. I notice that Neil's patch at 201460 includes changes that set flex=1 (where no value for flex had been set previously).
Craig Ringer, have you checked a current 1.5b build with the fix for bug 201379? How does that fix affect the issues you have seen? I think that vibrating VERTICAL splitter problem in your comment 26, if not bug 91662, may be bug 188138 -- which you have commented in, back in April.
Marc Schöchlin, if you are still reading your bugmail, please respond: the fix for bug 201379 is in Mozilla 1.4.1 and 1.5 Final. Your original report appeared to be a duplicate of that bug, despite all the gyrations following. If the bug has in fact been cleared up for you, please mark this bug as a duplicate of that one. Craig Ringer, I assume you've switched your focus to the other bugs discussed in recent comments; as you said in comment 26 "The original bug report appears to be talking about ... 201379." I would really like to see this bug closed.
I'd just missed the last note in which you asked for testing of the patch. I'll check it out soon and let you know how I go.
*** Bug 233032 has been marked as a duplicate of this bug. ***
duping based on comment 34