Closed Bug 27717 Opened 25 years ago Closed 25 years ago

repaint problems

Categories

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

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 28100

People

(Reporter: sspitzer, Assigned: danm.moz)

References

Details

(Keywords: platform-parity, Whiteboard: [PDT+] w/b minus on 02/25 - investigating. date unknown.) 

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?
*** Bug 27718 has been marked as a duplicate of this bug. ***
sorry about all those duplicates.  having problems submitting bugs with 5.0
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.
QA Contact: lchiang → laurel
seth, try this with viewmanager2 as well - it's in the debug pane of the
preferences...
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
Reassign to evaughan, nominate for beta1
Assignee: phil → evaughan
Keywords: beta1
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?
Putting on the PDT+ radar for beta1.
Whiteboard: [PDT+]
This all works fine on windows. And I haven't seen it on linix can you confirm?
Assignee: evaughan → pavlov
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.
my only guess would be that something is relying on painting in modal dialogs on
a timer.  i wouldn't recommend doing this. :-)
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.
Assignee: pavlov → 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.
Assignee: davidm → danm
Target Milestone: M14
Keywords: pp
Whiteboard: [PDT+] → [PDT+] investigating. no clues yet.
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.
Summary: [PP] repaint problems → repaint problems
Whiteboard: [PDT+] investigating. no clues yet. → [PDT+] investigating. date unknown.
Will move to pdt- on 02/25 if no fix.
Whiteboard: [PDT+] investigating. date unknown. → [PDT+] Must fix 02/25- investigating. date unknown.
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.
Corretion.  I kept saying bug 78100.  Of course I meant bug 28100.  Sorry about 
that.
Whiteboard: [PDT+] Must fix 02/25- investigating. date unknown. → [PDT+] w/b minus on 02/25 - investigating. date unknown.

*** This bug has been marked as a duplicate of 28100 ***
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Marking verified as duplicate.
Also verified this as fixed for mailnews scenarios using 2000-03-06-08
commercial build on linux rh6.0
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.