135000 - No progressmeter in status bar for mass-marking of messages

Status: NEW

(SeaMonkey :: MailNews: General, defect)

Description

[Matthias Versen [:Matti]]

win2k build 20020401..

I had a crash and all my mozilla mails were marked "unread".
I selected all messages and tried to mark them "read".

If you do that via the UI, the menu stays open and mozilla seems to hang.
I have 15000 messages in my mozilla folder and i waited >3min on my 
Athlon1.3Ghz,512 MB RAM and 2x60Gbyte IBM HDDs as IDE-Raid0 (they read very easy 
60Mbyte/s and more)

Please add a progressmeter in the status bar because I and many users would 
think that mozilla hangs.

Comment 1

[Håkan Waara]

I tried to patch the dbview to update the statusbar in every iteration of the
for-loop in ApplyCommandToIndices(), but obviously this bug is not fixed that way.

For some reason the whole app is freezing -- is this because the db is running
on the ui-thread or something, or am I just lost? :-)

Comment 2

[David :Bienvenu]

You don't want to update the status bar on every message marked read (that will
lock up the cpu, as you found out). Every 100 messages or so ought to be OK -
better yet is to update the status bar every half second or second, though that
might be overkill.

Comment 3

[Håkan Waara]

Matti reports that mailnews freezes until the whole operation is complete, so
updating every 100th message wouldn't make any difference. Any idea why it locks up?

Comment 4

[David :Bienvenu]

oh, it locks up because we update the status flags for all the messages in the
berkeley mailbox synchronously, without returning back to the main event loop,
on the ui thread. To fix this, we'd need to do something like search urls, which
do a little work, remember its state, set a timer, and return to the event loop.
When the timer fires, we do a little more work, and set another timer.

Comment 5

[Matthias Versen [:Matti]]

it's complety frozen and the menu is still open and you can't close it.
You can ask me if you need a testdatabase (compressed 3.37 MB)

Comment 6

[David :Bienvenu]

Thanks, I don't need a test case - what's happening is that we're doing 15,000
seeks and 15,000 reads and 15,000 writes in the local folder - that will take
some time. The fix is still as I described it above.

Comment 7

[Håkan Waara]

bienvenu: so, I am trying to understand the whole timer usage in
nsMsgSearchSession, and apply it onto the dbview.  It looks like it just returns
out to the main-thread, and then runs ThreadCallback after 0 ms (directly) ?

Would a sufficient fix be this: every 100th iteration change the status-feedback
of the mMsgWindow, return out to ui-thread to reflect the statusbar change, and
then after 0 ms somehow go back to the for-loop and continue with the next chunk
of 100 messages?

Comment 8

[Blu3]

Side note:
Doesn't mozilla already know which messages are unread?  Wouldn't it be much
more efficient to only un/mark those messages?

I.e. my lkml mbox has 40,000 messages.  With only five new emails, it's a few
seconds for me to click on each one to mark them read, but in order to mass mark
them, it takes almost a minute before I can use mozilla again.

I would still like a progress meter.  Until I realized what was happening (on a
slower cpu), I thought mozilla had locked up because it was apparently hung for
several minutes.

Comment 9

[Blu3]

FYI, setting mail.check_all_imap_folders_for_new = true for a large mailbox is
unusable.  if that mailbox takes more than N minutes to check, moz will break
itself by opening another connection and confusing itself with an invalid
message authentication code.  N being the period between mailbox checks.

If the above happens, the mbox being checked will show up with nothing in it.

Comment 10

[David :Bienvenu]

Is this on a UW server? How large a mailbox is it that takes more than NN
minutes to issue a SELECT on? We should be queing the second update and not
issuing two selects on the folder. Can you attach a protocol log showing this
problem? (Or send it to me directly?)
http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap

Comment 11

[Blu3]

Yes, UW.  This particular mailbox is about 42K messages.  I intentionally keep
it fat in order to provide a ready testing tool.

I'll restart and make a log.

Comment 12

[Blu3]

The generated log file is 25megs, bzip'd to 1 meg.  I'll send it directly to you.

Comment 13

[David :Bienvenu]

David, I suspect our discussion is meant to be going on in bug 18266

Comment 14

[Blu3]

sounds good to me. moving to bug 18266.

Comment 15

[Wayne Mery (:wsmwk)]

Bienvenu in comment #4)
> oh, it locks up because we update the status flags for all the messages in the
> berkeley mailbox synchronously, without returning back to the main event loop,
> on the ui thread. To fix this, we'd need to do something like search urls, which
> do a little work, remember its state, set a timer, and return to the event loop.
> When the timer fires, we do a little more work, and set another timer.

has this been fixed, or is there an open bug#?

Comment 16

[Wayne Mery (:wsmwk)]

comment 4 is addressed in an open thunderbird bug. someone could look it up and mark this dependent.

"no progress meter" aspect of this bug is not about a solid "hang", but I also wouldn't class it as ENH, so sev=normal