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.
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..
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.
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.
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.
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..