Open Bug 49202 Opened 24 years ago Updated 12 years ago

statusbar tells "Document Done.." overwriting current item on status bar

Categories

(SeaMonkey :: MailNews: Message Display, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

People

(Reporter: spam, Unassigned)

References

(Depends on 1 open bug)

Details

(Whiteboard: [ue2] [ish])

Attachments

(2 files, 1 obsolete file)

old bug, couldn't find it filed

build id 2000081509 linux:

After clicking "get mail" i would appreciate if statusbar kept displaying "no
new messages on server", if so was the case.
Now, instead, this message flash by so fast it can hardly be read, and is
swiftly replaced by "Document Done X.Xsecs"

Which document is done? Seems to me that piece of info is redundant, misleading,
and in addition it overwrites the info i really want to see; a confirmation
mailnews has actually finished searching for new mail on server.
hmmm, this is supposed to be fixed as per bug 
http://bugzilla.mozilla.org/show_bug.cgi?id=20176.
umm...not really - after the bug was marked fixed a comment accnowledge that
this problem still remains unsolved;

"------- Additional Comments From bienvenu@netscape.com 2000-07-26 14:43 -------
somewhat fixed - but it gets overwritten with document:Done immediately in the
imap case, just like the pop case. I'm working on that."

QA Contact: lchiang → esther
I'm going to turn this bug into a general case where "Document Done" always 
comes up so that the user can't see the previous item on the status bar.
Summary: statusbar tells "Document Done.." after mail is checked → statusbar tells "Document Done.." overwriting current item on status bar
*** Bug 47737 has been marked as a duplicate of this bug. ***
future per mail triage
Target Milestone: --- → Future
*** Bug 51258 has been marked as a duplicate of this bug. ***
OS: All
OS: Linux → All
Now that NS6 is out the door, can we get this fixed? This is very irritating for
my mail server situation. We have a time limit between consecutive calls to
check for mail so traffic is minimized. Since I'm never actually sure whether
the messages have been requested I tend to want to hit Get Msgs again -- which
would reject me and cause lots of problems.

This isn't just a problem for when no mail is recieved either. If i get 8
messages and don't notice it, then that mesage is blocked out by document done too.

What ever happened to the dialog window of "downloading messages" like in 4x ?

I think this might simply be a case of document done being use friviously. even
when I load mail and it accesses the mozilla mail-page, it says Document Done
while loading and then when done says Document Done X.XX seconds.

What Document is Done? It seems like Done is being used as default when it
should read the actual status.
Ninoschka, could this be yours? User Interface..
QA Contact: esther → nbaca
*** Bug 65030 has been marked as a duplicate of this bug. ***
Keywords: mozilla0.9.1
Keywords: nsCatFood
It works for me on 2001041421/Linux.
*** Bug 83291 has been marked as a duplicate of this bug. ***
*** Bug 92375 has been marked as a duplicate of this bug. ***
*** Bug 111483 has been marked as a duplicate of this bug. ***
QA Contact: nbaca → olgam
reassigning to ssu.
Assignee: putterman → ssu
(messenger/content/messenger/mailWindow.js)
329    _stopMeteors : function()
330     {
331       if(gTimelineEnabled){
332         gTimelineService.stopTimer("FolderLoading");
333         gTimelineService.markTimer("FolderLoading");
334         gTimelineService.resetTimer("FolderLoading");
335       }
336       this.ensureStatusFields();
337       // Record page loading time.
338       var elapsed = ( (new Date()).getTime() - this.startTime ) / 1000;
339       var msg = gMessengerBundle.getFormattedString("documentDoneTime",
340                                                     [ elapsed ]);
341       this.showStatusString(msg);
342       defaultStatus = msg;

"Document: Done" doesn't overwrite "There are no new messsages on the server"
if I remove this.showStatusString(msg). But is it the right fix?
How should it be?

Attached patch patch (obsolete) — Splinter Review
I believe it's not necessary to show "Document Done" after downloading mail.
Comment on attachment 73193 [details] [diff] [review]
patch

What happens if we display "Download new articles..." or something like that?
Is there code somewhere else to reset the string, or will it stay there with
this patch?

Please test the patch thoroughly.
Statusbar changes as below.

(1) Hit "Get Msgs" button

1-1: Connect: Host contacted, sending login information...
1-2: Receiving: message 1 of 2
1-3: Receiving: message 2 of 2
1-4: Received 2 of 2 messages
1-5: Document: Done (2.238 secs)

(2) Click in thread pane

2-1: Loading Document...
2-2: Document: Done
2-3: Document: Done (1.214 secs)

(3) Select "Compact this folder" in contextmenu for folder pane

3-1: Compacting folder testfolder1...
3-2: Document: Done (5.212 secs)


1-5 and 2-3 isn't necessary. But 3-2 should be replaced with another message.
Attached patch patch #2Splinter Review
show "Document: Done" if compacting mail finishes

I think "Document: Done" should be replaced with another message.
I will file a new bug if everyone agrees.
My patch reveals one more hidden bug.

If you click a newsgroup name in folder pane, statusbar changes as below.

4-1: Downloading 344 of 344 headers
4-2: There are no new messages on the server.
4-3: Document: Done (32.222 secs)

If my patch is applied, the last message is 4-2. But it should be
"Downloaded 344 of 344 headers" or "Document: Done".

http://lxr.mozilla.org/seamonkey/source/mailnews/news/src/nsNNTPNewsgroupList.cpp#270

*** Bug 72749 has been marked as a duplicate of this bug. ***
I filed bug 130560 for "no new messages"(#21).
Observed with Mozilla 0.9.9 on Win2k-SP2:

- Pre condition: the option Server Settings > Check for new mail on startup of a
POP account is enabled.

- Scenario: start Mozilla Mail; "Document:Done" is immediately printed on the
status bar, no matter if and how many msgs are downloaded.

- Post condition: the user doesn't know that a transaction took place.
Whiteboard: [ue2]
Whiteboard: [ue2] → [ue2] [ish]
Attached patch patchSplinter Review
The fix for bug 48436 made my patch(attachment 73193 [details] [diff] [review]) obsolete.
Attachment #73193 - Attachment is obsolete: true
Attachment #73346 - Flags: review?(ssu)
Attachment #106309 - Flags: review?(ssu)
Current trunk CVS: This bug is no more. WFM
Should perhaps be considered for the 1.* tree.
WFM? Don't you see "Done"?
oops the behaviour isn't 100% consistant.
Sometimes Done appears right away, sometimes "There are no new messages on
server" stays untill i mouse over a link or click a message.
Product: Browser → Seamonkey
There seem to be a number of bugs relating to the Mail window status bar.
I have a problem with a server that DOES have mail.
I click "get mail", the status bar says it is connecting and the toolbar
throbber and status bar progress bar look active. Then it all stops, and no mail
has arrived, and there is no indication of an error.

When I try again I get a message "This folder is being processed" etc.

Should I file a new bug for this or is it related?
Attachment #73346 - Flags: review?(ssu0262) → review?(bienvenu)
Attachment #106309 - Flags: review?(ssu0262) → review?(neil.parkwaycc.co.uk)
Comment on attachment 73346 [details] [diff] [review]
patch #2

this seems wrong when we're compacting all folders.
Attachment #73346 - Flags: review?(bienvenu) → review-
Assignee: ssu0262 → kazhik
QA Contact: olgam → mail
Comment on attachment 106309 [details] [diff] [review]
patch

David, do you have time to look at this.

(Cleaning up old review requests.)
Attachment #106309 - Flags: review?(bienvenu)
potentially helps news bug 130560. 

needs new patch owner.  afaict Koike Kazuhiko is gone

xref bug 95213
Assignee: kazhik → mail
Blocks: 130560
QA Contact: mail
I only use SM OS/2 branch for email so no point to CC me on this.
Assignee: mail → nobody
Priority: P3 → --
QA Contact: message-display
Target Milestone: Future → ---
Comment on attachment 106309 [details] [diff] [review]
patch

we no longer do this, and thus this patch has bit-rotted.
Attachment #106309 - Flags: review?(bienvenu) → review-
We now clear the status bar, instead of writing document done, so perhaps this can be grist for the mill of the status message overhaul that Bryan's working on.
It would be nice to have something tracking what the end state of a process looks like for bug 257942
Depends on: activitymgr
Is this really a Seamonkey bug, in which case it shouldn't likely be tied with the thunderbird activity mgr bug, or should this be moved to mailnews:core?
(In reply to comment #37)
> Is this really a Seamonkey bug, in which case it shouldn't likely be tied with
> the thunderbird activity mgr bug, or should this be moved to mailnews:core?
Attachment #106309 - Flags: review?(neil)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: