27717 - repaint problems

Status: VERIFIED DUPLICATE of bug 28100

(SeaMonkey :: MailNews: Message Display, defect, P3)

Description

[(not reading, please use [e-mail] instead)]

over the weekend I noticed a couple linux specific repaint problems.

1) in the imap password dialog, I can click on the remember password checkbox
but the check doesn't get drawn.  if I force an expose event (by covering and
uncovering the dialog with another window) it appears checked.  I am sure this
is not specific to imap.

2) messenger folder pane, if I click to expand a folder, and the folder pane
will not repaint.  again, if I force an expose event, it looks fine

3) messenger thread pane, if I click on a folder, the thread pane will not
repaint to show the messages.  (try loading inbox, and then another folder to
see this behaviour)

these problems are not happening on winnt.

evaughan, could this be related to your recent checkins to reduce the number of
reflows?

Comment 1

[Richard Zach]

*** Bug 27718 has been marked as a duplicate of this bug. ***

Comment 2

[(not reading, please use [e-mail] instead)]

sorry about all those duplicates.  having problems submitting bugs with 5.0

Comment 3

[laurel]

Another instance to check when verifying:  Newsgroups: download headers dialog
-- Checkmarking or changing radio buttons will not appear to take until you
cover the dialog and expose it again.

Comment 4

[Alec Flett]

seth, try this with viewmanager2 as well - it's in the debug pane of the
preferences...

Comment 5

[(not reading, please use [e-mail] instead)]

the viewmanager pref made no difference.

but this did:

if I run -mail, and open mail only (no browser), problems #2 and #3 seem to go
away.

this "two windows causes problems" is also noted in bug #27724

Comment 6

[Phil Peterson]

Reassign to evaughan, nominate for beta1

Comment 7

[(not reading, please use [e-mail] instead)]

another repaint problem that shows up with the "two window case" is menu
selection.

when I have messenger and browser up, and I try to select something in the
messenger menu, it never turns the current menu item the mouse is over "blue".

the menu selection works fine with just messenger

does that make sense?

Comment 8

[leger]

Putting on the PDT+ radar for beta1.

Comment 9

[Eric Vaughan]

This all works fine on windows. And I haven't seen it on linix can you confirm?

Comment 10

[laurel]

I don't think it was ever on windows, as the bug describes in the first line
"linux specific".

I'm seeing it in today's mozilla build on linux rh6.0. Very easy to see doing
Seth's reported cases #2 and #3.

Comment 11

[Stuart Parmenter]

my only guess would be that something is relying on painting in modal dialogs on
a timer.  i wouldn't recommend doing this. :-)

Comment 12

[Stuart Parmenter]

I was told David might be able to help...  I'm assuming the fact that this
dialog spikes my CPU useage to 100% has something to do with the reason that it
isn't painting.  If the painting queue never gets processed then you arn't going
to see anything happen.  Exposes probably have a high enough priority that they
do get processed.

Comment 13

[davidm]

Whoever told you that I could help was sadly misinformed as this surely has 
nothing to do with the common dialog code but with the dialog infrastructure. 
Danm on the other hand loves receiving these bugs.

Comment 14

[Alec Flett]

dan - one thing pav pointed out to me yesterday is that these net dialogs are 
taking up 100% CPU when they are active. He also noticed that the mouseover 
highlights are not happening on the buttons....

I'm wondering if certain exposure or paint notifications are never making it out 
of the event queue because something else is hogging or blocking it.

Comment 15

[leger]

Will move to pdt- on 02/25 if no fix.

Comment 16

[Stephen P. Morse]

Danm just told me about this bug.  It looks an awful lot like bug 78100 which I 
have been investigating a bit.  Big difference between these bugs is that 28100 
deals with the checkbox in the http authentication dialog whereas this bug 
involves the checkbox in the imap password dialog.  Also reluctant to mark the 
other as a dup of this one because this one loses its PDT+ status on 2/25 
whereas the other one keeps it until 3/3 ;-)

Here's an interesting point.  The checkbox problem occurs in imap (as reported 
here) and in http authentication (as reported in bug 78100.  But it does not 
occur in ftp authentication.  See my comments in bug 78100 about that.

Comment 17

[Stephen P. Morse]

Corretion.  I kept saying bug 78100.  Of course I meant bug 28100.  Sorry about 
that.

Comment 18

[Peter Trudelle]

*** This bug has been marked as a duplicate of 28100 ***

Comment 19

[laurel]

Marking verified as duplicate.
Also verified this as fixed for mailnews scenarios using 2000-03-06-08
commercial build on linux rh6.0