20129 - [FEATURE] Mozilla unresponsive during load, sort

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect, P2)

Description

[Richard Zach]

Browser and mail windows becomes unresponsive when opening mail or news folders
or when sorting message headers.  At the current performance levels (1 minute +
to open/sort n.p.mozilla.builds) this is quite annoying.

Expected behavior: The user should (a) get a message in the progress bar that
the folder is being opened (x of y messages, etc) or being sorted, and (b)
should be able to interrupt the process by, e.g., selecting a different coulmn
to sort on or opening a different newsgroup/folder.

Build 1999112508 Linux

Comment 1

[Phil Peterson]

Reassign to bienvenu. David, do you want to call this a dup of bug 18739?

Comment 2

[David :Bienvenu]

well, this is really asking for incremental rdf content building, sorting,
reflow, etc. That would be up to rdf, and there's not much I can do about it.
Speeding all this up would help quite a bit, but it wouldn't fix the bug as
written. Giving back to you to decide what you want to do about it, cc'ing scott
and rdf folks to see if he knows about any plans for rdf/tree control to be
built up incrementally. My guess is this is a won't fix.

Comment 3

[Phil Peterson]

Ok, then let's make this bug dependent on bug 18739 and we can re-evaluate it
after performance improves. If we get a lot faster, we might not need feedback,
but if we don't, feedback will be important.

Comment 4

[Richard Zach]

However, issue (b) above is not really covered in the other bug.  When you open
a newsgroup with a large number of messages, the thread pane isn't even being
drawn yet, but all you can do is watch the progress bar as it tells you
"Received 5000 of 10500 headers).   Clicking "Stop" doesn't stop the header
download, and clicking another newsgroup has the effect of MailNews downloading
another 10000 headers simulatenously.  Opening a mail folder also doesn't stop
the header download.  (Should this be a different bug? Newsgroup header download
does not stop when clicking stop, or when selecting a different newsgroup or
mail folder.)

Comment 5

[Phil Peterson]

Yes, I think that is a separate bug, so I entered it as bug 20540

Comment 6

[Chris Waterson]

This is really an RDF problem. I'm stealing from phil. It occurs in the file
browser as well.

Comment 7

[leger]

Putting on PDT+ radar for beta1.

Comment 8

[Phil Peterson]

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

Comment 9

[Chris Waterson]

phil: I need a little "guidance" on this one. I think we have two ways to deal 
with this problem.

1. Make load and sort "fast enough" so that being unresponsive is OK. (E.g. I 
know that scott, robert, and I are trying to do this now.) We need to let the 
user know that we're going out to lunch for a while (e.g., hourglass cursor).

2. Allow UI events to continue flow by making sort and load operations 
asynchronous and incremental. bienvenu has already done this for the "download 
the folder contents" part of these operations, so what I'm proposing is that 
we'd also do this for the compute operations as well.

IMO, option (1) is the preferred option, because it's where we eventually want 
to be anyway.

Comment 10

[Phil Peterson]

Chris, yes, I think (1) is the right thing. I sort of alluded to that in my 12/1
comments. It would be a bummer if we couldn't make sorting fast enough that it
needed to be async/incremental.

Comment 11

[Chris Waterson]

phil: i'm going to reassign this back to you. I think we should create a new 
bug for "adding progress feedback to mail/news UI." Turns out that we -do- have 
cursor control with CSS2 properties: e.g., see this thread and its replies on 
n.p.m.xpfe:

news://news.mozilla.org/389A5F9E.E78FFD6E%40gte.com

It's possible to either do something like this from JS:

  // Make the cursor be a 'wait' cursor in this window
  window.style.cursor = 'wait';

or via a style rule, e.g.,

  window.busy { cursor: wait !important }

Which would cause adding a 'busy' class to the window to trigger the wait 
cursor. I'd recommend we get the UI geeks (hangas, law, ben) to sort out the 
best way to do this.

  

  

Comment 12

[Phil Peterson]

Ok, reassigning to hangas

Comment 13

[Phil Peterson]

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

Comment 14

[hangas]

Marking with 2/11 completion date.

Comment 15

[hangas]

Bumping completion date out one week.  First attempts to modify cursor with style 
in global.css failed.

Comment 16

[hangas]

Changing completion date to depends 27849.  Currently the cursor cannot be set 
for a window from JS.  It seems to only work when set permanently in the xul.  
Based on this I recommend that we remove the PDT+ and let beta1 go out without 
this wait cursor.  Removing PDT+ to put on PDT radar.

Comment 17

[hangas]

Bumping to M15

Comment 18

[hangas]

Mass moving to M17

Comment 19

[John G. Myers]

Why is mailnews waiting for the last caption to download before starting to do 
the load and sort?  The CPU is probably idling quite a bit while the client is 
waiting for those captions to download.

The load and sort should be done incrementally while the captions are still 
coming down from the server.  Eventually, you may even be able to let the user 
start reading messages while the captions are still being downloaded.

Comment 20

[Chris Waterson]

I think this is what was tried originally, but the overhead of incrementally 
reflowing the tree widget *each time* a message came in out-weighed the 
advantages of actually having data there. (To the tune of being completely 
unusable while messages arrived, and about ten times slower overall.)

Since then, the tree code has been made to suck a great deal less, and nisheeth 
has introduced his "batched reflow" code. It may be worth experimenting with 
this again.

Comment 21

[John G. Myers]

Best would be to reflow when the network code blocks on the server connection.

Client-side filters make this a little more challenging.  If this could be pulled 
off, it would be a great win for POP over slow connections.

Comment 22

[selmer (gone)]

We have a number of places in the mail UI where we want to use this now.
Bumping back into M16.  Adding beta2 keyword.

Comment 23

[selmer (gone)]

Scott, clearing Hangas' plate for skins work.  Probably need to reassign some of 
these again.

Comment 24

[scottputterman]

moving to M18.

Comment 25

[fenella]

QA-assigned to fenella

Comment 26

[leger]

Putting on [nsbeta2-] radar. Not critical to beta2.

Comment 27

[Ben Bucksch (:BenB)]

It's not clear to me what this bug is about now. Is the the whole app (including
browser) completely blocking? In which cases (header download, load, sort)?
Completely blocking during download would be a very bad thing. Also, this bug is
only about msg headers, i.e. the thread pane, right? If yes, the summary should
be adjusted (we are unresponsive during msg load (e.g. msg display) as well).

Comment 28

[Phil Peterson]

The whole mozilla process blocks when (re)loading the thread pane. That's what
this bug has always been about. It's not about message display performance, or
message download performance. Nominating for nsbeta3 to *at least* put up the
platform-specific "busy" cursor while this is happening. Of course, making it
faster would be great too :-)

Comment 29

[lchiang]

+ per mail triage for busy cursor feedback

Comment 30

[scottputterman]

fix checked in. Busy cursor comes up around folder loading, sorting and 
threading. 

Comment 31

[fenella]

Linux (2000-08-30-08 M18)
Win32  (2000-08-30-06 M18)
Mac  (2000-08-30-08 M18)
This has been fixed.