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

NEW
Unassigned

Status

19 years ago
7 years ago

People

(Reporter: spam, Unassigned)

Tracking

(Depends on: 1 bug)

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ue2] [ish])

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

19 years ago
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.

Comment 1

19 years ago
hmmm, this is supposed to be fixed as per bug 
http://bugzilla.mozilla.org/show_bug.cgi?id=20176.
(Reporter)

Comment 2

19 years ago
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."

Updated

19 years ago
QA Contact: lchiang → esther

Comment 3

19 years ago
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

Comment 4

19 years ago
*** Bug 47737 has been marked as a duplicate of this bug. ***

Comment 5

19 years ago
future per mail triage
Target Milestone: --- → Future

Comment 6

19 years ago
*** Bug 51258 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 7

19 years ago
OS: All
OS: Linux → All

Comment 8

19 years ago
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..

Updated

19 years ago
QA Contact: esther → nbaca
(Reporter)

Comment 10

18 years ago
*** Bug 65030 has been marked as a duplicate of this bug. ***

Updated

18 years ago
Keywords: mozilla0.9.1

Updated

18 years ago
Keywords: nsCatFood

Comment 11

18 years ago
It works for me on 2001041421/Linux.

Comment 12

18 years ago
*** Bug 83291 has been marked as a duplicate of this bug. ***

Comment 13

18 years ago
*** Bug 92375 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 14

18 years ago
*** Bug 111483 has been marked as a duplicate of this bug. ***

Updated

18 years ago
QA Contact: nbaca → olgam

Comment 15

18 years ago
reassigning to ssu.
Assignee: putterman → ssu

Comment 16

17 years ago
(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?

Comment 17

17 years ago
Created attachment 73193 [details] [diff] [review]
patch

I believe it's not necessary to show "Document Done" after downloading mail.

Comment 18

17 years ago
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.

Comment 19

17 years ago
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.

Comment 20

17 years ago
Created attachment 73346 [details] [diff] [review]
patch #2

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.

Comment 21

17 years ago
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

Comment 22

17 years ago
*** Bug 72749 has been marked as a duplicate of this bug. ***

Comment 23

17 years ago
I filed bug 130560 for "no new messages"(#21).

Comment 24

17 years ago
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.

Updated

17 years ago
Whiteboard: [ue2]

Updated

17 years ago
Whiteboard: [ue2] → [ue2] [ish]

Comment 25

17 years ago
Created attachment 106309 [details] [diff] [review]
patch

The fix for bug 48436 made my patch(attachment 73193 [details] [diff] [review]) obsolete.

Updated

17 years ago
Attachment #73193 - Attachment is obsolete: true

Updated

16 years ago
Attachment #73346 - Flags: review?(ssu)

Updated

16 years ago
Attachment #106309 - Flags: review?(ssu)
(Reporter)

Comment 26

16 years ago
Current trunk CVS: This bug is no more. WFM
Should perhaps be considered for the 1.* tree.

Comment 27

16 years ago
WFM? Don't you see "Done"?
(Reporter)

Comment 28

16 years ago
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

Comment 29

14 years ago
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?

Updated

14 years ago
Attachment #73346 - Flags: review?(ssu0262) → review?(bienvenu)

Updated

14 years ago
Attachment #106309 - Flags: review?(ssu0262) → review?(neil.parkwaycc.co.uk)

Comment 30

14 years ago
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

Comment 33

11 years ago
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 34

11 years ago
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-

Comment 35

11 years ago
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: 257942
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.