Closed Bug 131733 Opened 22 years ago Closed 16 years ago

Flickering of mail-preview-window - after enlarging the mailheader

Categories

(SeaMonkey :: MailNews: Message Display, defect)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 201379

People

(Reporter: schoechlin, Unassigned)

References

Details

(Keywords: hang)

Attachments

(7 files)

Mail window with initial message selected
72.29 KB, image/png
Details
mid-jump #1
75.38 KB, image/png
Details
mid-jump #2
71.59 KB, image/png
Details
separator bar pushed out to left by message
63.62 KB, image/png
Details
Everything has settled down to a stable state here
77.70 KB, image/png
Details
With this message it jittered 5+ times then stopped with the bar on the left.
114.06 KB, image/png
Details
CPU pegged at 100% due to redraws
40.84 KB, image/jpeg
Details 
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
Keywords: hang
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. 
Critical severity.
Severity: normal → critical
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?
Severity: critical → normal
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?
Severity: normal → critical
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** 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.
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.
Attached image 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.
Attached image 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.
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!
Jumping, jittering and repeated half-completed redraws are over. Everything has
settled down to display the next message.
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.
Hi all

I've just started testing with a self-built 1.4 and the bug is present, but less
obvious. Interesting how it varies.

I've had a bit of an idea that I was hoping someone might be able to help with.
If there's a set of calls that could be used to wrap the redrawing of the
message pane such that (very-pseudocode):

<user clicks on next message>
changeSelectionTo(newmessage);
disableDrawing(mozillaMail3PaneBody)
drawMessageHeaders(newmessage);
drawMessageBody(newmessage);
drawAttachments(newmessage);
drawScrollBars(newmessage);
enableDrawing(mozillaMail3PaneBody);

in other words, any jumping and jittering would be supressed by just not
redrawing until it was all done. It'd be an ugly workaround, but there seem to
be a bunch of different problems causing the layout and jitter issues, and
perhaps an ugly workaround is called for to get it /working/ for now.

Specific issues I'm seeing:

 - vertical separator (between mailboxes pane and messagelist+message panes)
gets pushed to the left by display of a message with very long subject or other
headers. Causes mailbox name truncation, annoying repeated redrawing while
skipping from message to message. Especially severe in threaded message display.

 - Attachments box in message headers area gets pushed out to the right of the
headers area (and out of the mozilla window) by long message headers, especially
from: address. Causes: inaccessable attachments

 - scroll bars on message display pane sometimes fail to draw when displaying a
message with very long subject &/or from address as the current message. Causes:
user confusion, need to scroll using arrow keys, annoying redraws.

I also notice that mozilla /never/ truncates From addresses in the main message
display. Perhaps it should truncate them like it does mailbox names and
subjects, either:

"blah .. blah <bob@ ... >"

or "blah blah ..."

It seems like assumptions about the minimum resolution are responsable for a lot
of these issues. It's like the total width of all the components Moz is trying
to draw is greater than the mozilla window size. Certainly this is the case for
the vanishing attachments box, and probably the scroll bars as well. It may well
be the root of the problem with the vertical separator jumping around, too.
Being able to lock that thing in place would help a /lot/...

I'm looking at the code now, perhaps in 100 years I'll be able to fix something.
I've got to learn the Mozilla codebase, C++, JavaScript, XUL etc enough to
figure out what's going on... and I've got plenty else going on too. I'll give
it a try, but some pointers would be /wonderful/.
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 v1.4.0.3J)
Gecko/20030728 Mozilla Firebird/0.6.1
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. ***
Product: Browser → Seamonkey
Assignee: sspitzer → mail
QA Contact: esther → search
duping based on comment 34
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: