40663 - View -> headers near freezes everything

Status: VERIFIED FIXED

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

Description

[R.K.Aa.]

Linux M16 2000-052520
Saw this first time in the previous morning build:

Select a mail
Go go View, headers, all
It takes a little while and then displays
Then try to do *anything*:
Things have slowed down to close to a grinding halt.

Took over 5 minutes to disable View headers again (till "normal") and another 5
minutes before this had activated.

Also: Earlyer, when dragging mouse over addressfield etc. in a displayed mail ,
a kind of popup appeared, showing the "all headers" info. This doesn't seem to
activate at all anymore.

Comment 1

[scottputterman]

reassigning to mscott.

Comment 2

[Scott MacGregor]

Do you see something about box style caches getting blown away? I've seen that
recently.

Comment 3

[R.K.Aa.]

When selecting "View - headers - all" this comes in console:
OpenURL from XUL


STYLE CHANGE REFLOW. Blowing away all box caches!!
STYLE CHANGE REFLOW. Blowing away all box caches!!
STYLE CHANGE REFLOW. Blowing away all box caches!!
STYLE CHANGE REFLOW. Blowing away all box caches!!
stopping meteors 1
Document: Done (3.637secs)
stopping meteors
---
When afterwards selecting "View - headers - normal":
OpenURL from XUL


STYLE CHANGE REFLOW. Blowing away all box caches!!
STYLE CHANGE REFLOW. Blowing away all box caches!!
STYLE CHANGE REFLOW. Blowing away all box caches!!
STYLE CHANGE REFLOW. Blowing away all box caches!!
STYLE CHANGE REFLOW. Blowing away all box caches!!
STYLE CHANGE REFLOW. Blowing away all box caches!!
STYLE CHANGE REFLOW. Blowing away all box caches!!
STYLE CHANGE REFLOW. Blowing away all box caches!!
stopping meteors 1
Document: Done (2.722secs)
stopping meteors
-

If mailbody has quoted lines (>) and html formatting, the whole process take
even longer, but that is likely another bug.

NOTE: This "view all" bug behaves at it's dramatically worst (!!!) when the
displayed "all headers" is longer than the visible page. (Also note lack of
scrollbars).

Comment 4

[Scott MacGregor]

cc'ing evaughan. For some reason we are doing something in the message pane that
makes us think we have to blow away all box caches way more than we should be. I
don't know what that is yet.

nominating for beta2.

Comment 5

[leger]

Putting on [nsbeta2+] radar for beta2 fix.  Let us know if it becomes dogfood.

Comment 6

[R.K.Aa.]

I'm not quite sure you realize how bad this bug is..
The "blowing away" part doesn't seem to be the problem.
The problem is a 5 - 15 minute freeze, freezing everything - the entire GUI - if
i am silly enough to click the "view" menu again in an attempt to "view headers
normal" again. This "worst case" occure when only part of the header will be
visible in the messagepane. Someone should test this:

Resize mail till only the "normal header" + 5 lines of mailbody displays.
Then select "view headers -> all".
Then slowly get a feeling something is going very wrong..
and try to click "View" menu again

Tadaa.. soon your whole X session (all windows) - are blocked.
Cursor changes shape (top tilted left)- preparing for a dropdown-menu that won't
appear in "ages.
If you don't have time for this, you kill X with ctrl+alt+backspace when you've
had enough.

Also: Mail when restarted appears with the same size, still trying to display a
"header all". "Headers all" is a dangerous date nowadays, in other words.
A workaround is to edit prefs.js manually but that isn't an "intuitive"
measurement for common users.I think this should either be fixed before nsbeta2
or "view headers all" be disabled again for that release.

Comment 7

[R.K.Aa.]

bug 44303 can be related to this one.

Comment 8

[scottputterman]

Is this still happening and is it only on Linux?  I know I've tried this on 
Windows recently and not had this problem.

Comment 9

[R.K.Aa.]

2000-070120
It doesn't freeze, it just blinks black when using menus while "headers all" are
displayed, and the grey area indicating selected column is messed up (split) and
the "blowing away all box cache" output remains. But it doesn't freeze. :)

Comment 10

[scottputterman]

Scott, just a reminder from today's staff meeting that if this isn't something
you can reproduce that we should either mark this 7/13 or cut it.

Comment 11

[Scott MacGregor]

I don't see this problem any more on my windows and linux machines. marking as
fixed. 

Comment 12

[lchiang]

Kristin - does this still happen for you or is it ok now?  If it's slow, we 
should open a separate bug on that.

Comment 13

[R.K.Aa.]

As commented on the 1st, it doesn't appear to happen now.
Verifying fixed. (Linux, build 2000-071321)