The Headerbox flickers in size

VERIFIED FIXED

Status

SeaMonkey
MailNews: Message Display
--
blocker
VERIFIED FIXED
16 years ago
13 years ago

People

(Reporter: Andreas Sigg, Assigned: (not reading, please use seth@sspitzer.org instead))

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020310
BuildID:    2002041711

Immediately after the start, the mailtools headerbox,
that is the box which contains the mail headers, 
cant seem to decide in which side it runs and begins
to flicker. Its unusable, and you cant look at it 
for long without feeling pain.

Reproducible: Always
Steps to Reproduce:
1. Start the mailtool
2.
3.

Expected Results:  A serious bug which should be fixed.

The bug shows in SuSE Linux 7.3 and 8.0.
(Reporter)

Comment 1

16 years ago
I have found other Bug-Descriptions from "Spitz*" which contain
flicker in their summary and describe the same bug.
You cannot reproduce the bug if you have not the same mails in the
folder.
After moving the mail I found that it appeard when a certain mail
comes in the same folder with some other mails.
I was able to reproduce the bug this way one time. Then for
whatever reason I was not able to reproduce the bug for a 
sncd time.
At this point of time I guess the only important thing on this
bug is the solution: move the mails somewhere else. If it 
does appear in the other folder, try to separate the mails
into different folders until you get a stable folder again.
If you have many mails the problem might be worse althou..
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
(Reporter)

Comment 2

16 years ago
With some help of my friends I found out more about the bug. The above 
solution works but the description has errors.
It does not matter if it is a certain mail mixed with other certain 
mails in the same folder.
Solution:
What matters is the size of the headerbox - that is the box containing
the headers - in relation to its content.
It _may_ happen that the algorithm for the automatic setSize() of this
box does fail, and the box starts to flicker.
Whats unhappy with this bug is that you cant grab the size-bar to
resize the box manually, because it flickers too much to do this.
So the only solution is to remove/move away a mail from the flickering
folder, or to drop another mail into the folder which can be more
convenient because you dont have to keep the folder open for this
and thus you dont have to look at the flickering.
After you have done this, the flickering should vanish. Now you can
resize the headerbox manually and then move the mail you have added
back into the folder which you took it from.
Maybe someone find the time to check the auto-resize algorithm to
fix the problem at its source. It should imho not be allowed to
do more than one resize after the selection of a folder or the
startup of the mailtool.
(Reporter)

Comment 3

16 years ago
Just heard that it is not the automatic resize but the decision
if the resize-bar has to be shown which hangs and causes the
flickering.
This makes sense of you consider that the resize-bar itself
takes some space, and in some situations it is this space that
drops into the inverval of uncertainty that makes the algorithm
switch back and forth in the decision.
(Reporter)

Comment 4

16 years ago
Ok, my last msg was entire **** since the resize bar is always shown.
The idea was rather that the scrollbar which come into play when
the headerbox cant display all headers causes the flickering, 
since they seem enlarge the headerbox and thus cause the same
algorithm which displays the scrollbars to switch them off
again, and so forth.
(Reporter)

Comment 5

16 years ago
This comment adresses the programmer folk:
its clear that nobody wants to loose one sinlge pixel to spend it
into the headerbox if it isnt needed there, so I dont
suggest that someone spends extra-pixels to avoid the
interval of uncertainty which causes the automatic
scrollbar-popup to alternate its behavior.
But.. the problem should be solvable somehow. Maybe it is
possible to read the actual height of the headerbox before
switching off the scrollbar, and after the resize-function
of the header has done its thing maybe you can poke the
value which you have read back into the length as it should be..

Comment 6

16 years ago
Verified invalid.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.