66860 - [Meta] Include account name in all account-related interactions: status bar messages, error alerts, username/password prompts [POP3, IMAP, News; incl. improve status line text when sending/receiving/getting/downloading/fetching new messages]

Status: ASSIGNED

(MailNews Core :: Backend, enhancement)

Description

[Niko Pavlicek]

when you download new mail messages the account name should be mentioned in the
status line, e.g.:

"There are no new messages on the server"	should be:
"There are no new messages on the server for the account [account name]"

"Connect: Host connected, sending login information..."		should be:
"Connect: Host connected, sending login information for [account name]..."

"Downloading message x of y"	should be:
"Downloading message x of y for [account name]"

Especially if you have more than one account whose messages get downloaded at
startup the current status messages aren't clear enough.

Comment 1

[Matthew T (active 1999-2002)]

If we are checking several accounts at once, shouldn't we be doing the opposite
-- saying `Connecting to servers ...' instead of `Connecting to server ...', and 
then saying `Downloaded x of y messages ...', where x and y are both totals for 
all checked accounts? Otherwise we'll have a spastic indicator problem, where the 
account that finishes being checked the last `wins' in that it is the one that 
has its final status displayed.

Comment 2

[Niko Pavlicek]

ok, it is ok to have:
"Connecting to servers [account name, account name2, account name3, ..]..."

Comment 3

[timeless]

if we're connecting to multiple servers simultaneously, sure, but i think 
that's unlikely

Connecting to servers ... server1
[status ...]
[Done]
Connecting to servers ... server2
[status ...]
[Done]

Personally I want to know how many messages are on a single server.  If I want 
to know how many messages i got total i'll check the mail status bar after the 
app finishes downloading, or i'll check the number of total new messages in 
inbox and subtract the number of old new messages.

Comment 4

[Keyser Sose]

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

Comment 5

[Tuukka Tolvanen (sp3000)]

Since bug 75859 got dupl'd I'll mention here that this applies to alert dialogs
too, e.g. 'Failed to connect to the server' should include server name.

Comment 6

[Andrew Taylor]

Attachment: Displays account name in POP3 statusbar messages

Comment 7

[Andrew Taylor]

The patch I've attached puts the account name in the POP3 status bar messages. 
It doesn't address IMAP servers or the multiple server issues discussed at all,
but hopefully it can be used as a starting point.

Comment 8

[R.K.Aa.]

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

Comment 9

[Tuukka Tolvanen (sp3000)]

Unless bundling the alert and statusbar issues together is necessary for the
fix, might it be a good idea to spin off the alert problem (reopen, say, bug
75859 (bug 95302 = dup of that)), considering that it seems a more
straightforward thing to correct, and is more important ("useless alert, please
press ok") than transient statusbar messages? The alert message stuff doesn't
seem to be in this patch anyway as far as I can tell

Comment 10

[Karen Huang]

Nominating nsbeta1 based on PRD: improving error handling.

Comment 11

[robinf]

I think that Niko's original proposal provides the best feedback for the user.
In looking at the status bar, I've noticed that after the get msg
activity/status messages for the last account is done, the status displays
"Document: Done". Apparently, the status message for the last account to be
checked does not persist (so we don't have the problem of the "last account wins"). 

Comment 12

[scottputterman]

reassigning to ssu.

Comment 13

[R.K.Aa.]

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

Comment 14

[R.K.Aa.]

modifying platform and OS based on dups

Comment 15

[Joel Nelson (don't send email)]

The account name should be used for dialog-box error messages in addition to
just status-bar messages.   For progress while downloading messages one
suggestion would be to (by preference) have a drop-down (Mac OS X) or pop-up
(other OSes) box showing progress on all accounts.

Comment 16

[Olga]

I remove nsbeta1- keyword - it was for MachV.

Comment 17

[Olga]

Now I add 'nsbeta1' keyword for Buffy. Sorry, it's faster to edit multiple bugs
at once than manually go to each and remove minus.

Comment 18

[Samir Gehani]

Mail triage team: nsbeta1-

Comment 19

[:aceman]

This still exists in 1.3.1 and probably up...

My suggestions:
version 1 - add a fixed string (e.g. [account name]) when changing to a new 
account to the start of the status bar and write all successive status messages 
(which would then require absolutely no change) to the right of this string. I 
don't know if the status bar allows such manipulations in current 
implementation.

version 2 - do not touch the status bar, instead, indicate the current account 
being processed. Mark it somehow, select, highlight...

Comment 20

[Daniel Wang]

was gonna file a dupe of this

Instead of fixing these (dependent) bugs one by one, we need to be consistent
and allow users to choose between username and account name. We should have
global pref for controlling this

Comment 21

[[e-mail]]

Comment on attachment 34637 [details] [diff] [review]
Displays account name in POP3 statusbar messages

I can't exactly test this, given that it's somewhat bitrotted...

>-#LOCALIZATION NOTE (4002): Do not translate %lu in the following line.
>+#LOCALIZATION NOTE (4002): Do not translate %lu or %S in the following line.
> # Place the word %lu where the number of messages should appear.
> # The first %lu will receive the number of messages received so far;
> # the second %lu will receive the total number of messages
>-4002=Receiving: message %S of %S
>+# the %S will receive the account name
>+4002=Receiving: message %S of %S for account '%S'
It would be nice if the code was fixed to make the note accurate ;-)

>       mailnewsUrl->GetServer(getter_AddRefs(server));
>       NS_ENSURE_TRUE(server, NS_MSG_INVALID_OR_MISSING_SERVER);
>       m_pop3Server = do_QueryInterface(server);
>-      if (m_pop3Server)
>+      if (m_pop3Server) {
>         m_pop3Server->GetPop3CapabilityFlags(&m_pop3ConData->capability_flags);
>+        server->GetPrettyName(getter_Copies(m_accountName));
>+      }
Why inside the if?

>+            PRUnichar * statusTemplate = nsnull;
>+            mStringService->GetStringByID(POP3_CONNECT_HOST_CONTACTED_SENDING_LOGIN_INFORMATION, &statusTemplate);
nsXPIDLString?

Comment 22

[Andrew Taylor]

Yay, a review after almost 3 years.  I'll see if I can get this patch up-to-date
on the trunk.

Comment 23

[Andrew Taylor]

Attachment: Displays account name in POP3 statusbar messages v2

Here is my original patch, updated to the latest code.	I've also fixed up the
issues pointed out by Neil.

Comment 24

[Mike Cowperthwaite]

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

Comment 25

[Slyoldfox]

and what about IMAP accounts?

Comment 26

[louis bennett]

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

Comment 27

[louis bennett]

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

Comment 28

[louis bennett]

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

Comment 29

[David :Bienvenu]

I think this is worth driving in. We'll need to fix the thunderbird strings as well.

And I don't know if we want to say account or server.

Comment 30

[Karsten Düsterloh]

> I think this is worth driving in. We'll need to fix the thunderbird strings
> as well. 
> And I don't know if we want to say account or server.

I'd vote for 'account' if we display the custom account name and for 'server' if
not. Note also that some of the strings touched here have changed meanwhile!

Comment 31

[:aceman]

(In reply to comment #29)
> And I don't know if we want to say account or server.

Definitelly account, because it is unambiguous (if not, kick the user:)). You
can derive the server from the account, but not the account from the server
name. I have 3 account on the same real server. When using pop3 filtering
antivirus, all accounts are directed to localhost. Etc.

Or we can have both. The status can read:
[account] Connecting to server <server>...
[account] Logging in...
[account] Receiving message X of Y...

Comment 32

[Wayne Mery (:wsmwk)]

(In reply to comment #29)
> I think this is worth driving in. We'll need to fix the thunderbird strings as
well.

Need someone to take ownership to update the patch. Andrew hasn't responded.
Assigned (temporarily I hope) to [e-mail]

Comment 33

[Karsten Düsterloh]

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

Comment 34

[Karsten Düsterloh]

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

Comment 35

[Wayne Mery (:wsmwk)]

per Karsten 10/10/2005:
"The first problem is that this patch only tackles single POP3 servers
(at least Andrew says so in comment #7), ie IMAP, Movemail and NNTP are
missing.
The second problem is that it doesn't touch alerts, only statusbar changes.
Third, it's bitrotted after all these years."

Comment 36

[Magnus Melin [:mkmelin]]

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

Comment 37

[Boris]

There is another problem in the status line message.  While my folders get compacted, I continue working on other things.  If I delete a message or move it to another folder, the compacting message gets stepped on and lost.  Perhaps have two lines in the status bar would be a way to display information about background activities (compacting) and user activities (deleting message) at the same time without losing the information from the background activity.

Comment 39

[Wayne Mery (:wsmwk)]

from a QA standpoint, my prefence is blocking TB3

Comment 42

[David Ascher (:davida)]

not blocking.  should make sure to get ui-review on any patch like this.

Comment 43

[Magnus Melin [:mkmelin]]

Not a primary focus for the thunderbird3 release; wanted- don't indicate we wouldn't accept patches.

Comment 49

[David :Bienvenu]

Attachment: add host name to imap server alerts, and folder name, if relevant

I know that we want to revamp the way we do alerts in general, but I think we'll still want to present the extra information about hostname and folder in any case, and this patch gets us further down that road.

It affects two main cases - when the IMAP server says NO to a command, and we want to tell the user what the server said, and when the server tells us to put up an alert (e.g., the server is going down in five minutes, or, you're over quota). In the "NO" case, I've added the host name and optionally, the folder name, to the message, and in the alert case, I've added the server name to the alert message.

Comment 50

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 414521 [details] [diff] [review]
add host name to imap server alerts, and folder name, if relevant

Why are the server and folder command failed alerts different?  I might not understand these well enough but I expected they would all take a similar format to the folder command message.

i.e. use the account name in the beginning of the message as that's the most likely recognizable string (compared to the server name).  Include the server name next in case the person has multiple servers configured.

Maybe something like:

"$account_name reports: $more_specific_message"

Not very friendly though.

Comment 51

[David :Bienvenu]

I deliberately used the host name instead of the account name because these errors tend to be rare, and the actual host name can be useful in reporting and diagnosing the error. We do the same for errors like not being able to connect to the server. In other words, for normal status messages, like gloda indexing, we use the account name, but for server error issues, we try to use the host name. I can switch it to the account name if that seems too geeky.

Comment 52

[David :Bienvenu]

(In reply to comment #50)
> (From update of attachment 414521 [details] [diff] [review])
> Why are the server and folder command failed alerts different?

They're quite similar, actually. The folder command failed alert says something like:

The current operation on 'folder name' did not succeed. The mail server <host name> responded: response

and the server command says

The current command did not succeed. The mail server <host name> responded: response.

I could use command/operation in both to be consistent. The difference is really whether the imap command requires a folder to be selected or not. The most common folder error is "mailbox does not exist" so including the folder name is very helpful.

Comment 53

[Bryan Clark (DevTools PM) [:clarkbw]]

just using my account as an example where I'm clarkbw @ gmail but my server is imap.googlemail.  If we assume an account setup using our new account 'auto-magic-wizard' then all I would really know about my account is my own email.  So I'd suggest including the host name in those dialogs where it helps with the debugging but I'd also always include the account name as that's what we show in the Folder Pane and other pieces of the UI.

Comment 54

[Mybeau31]

(In reply to comment #49)
> Created an attachment (id=414521) [details]
> add host name to imap server alerts, and folder name, if relevant
> ....snip ...
> It affects two main cases - when the IMAP server says NO to a command, and we
> want to tell the user what the server said, and when the server tells us to put
> up an alert (e.g., the server is going down in five minutes, or, you're over
> quota). . snip .

Thanks for the patch, David. 
But it is limited to IMAP accounts. 
I understand that it is not "easy" to patch for POP accounts.
Could you please take some time to quickly explain why ? Thank you David

I would be glad to know the account/server name for POP accounts in case server is long to reply (not rare since I have several POP accounts with servers all around the world).
It is not user friendly to have to check each server to know which one must be ignored for some time.

Comment 55

[David :Bienvenu]

I did IMAP first - we'll get to POP3 next.

Comment 56

[Mark Banner (:standard8)]

David - are you going to address Bryan's comment 53 or are we moving forward with the patch as-is?

Comment 57

[David :Bienvenu]

Comment on attachment 414521 [details] [diff] [review]
add host name to imap server alerts, and folder name, if relevant

I'm definitely going to address Bryan's comments, but 3.01 stuff has consumed me (and this isn't going into 3.01). Removing review requests.

Comment 59

[David :Bienvenu]

Attachment: use account name instead of hostname in alerts

this switches over to using the account name in the alerts. It also hides the new strings in a place where BenB can't find them and bitrot them with his new strings :-)

Comment 60

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 436328 [details] [diff] [review]
use account name instead of hostname in alerts

heh, looks good

Comment 61

[David :Bienvenu]

Attachment: fix for imap alerts

This adds the imap account to various imap alerts and messages. These messages seem to be showing up in the activity manager, at least on Tb, but I think they're going to end up in system alerts before too long.

Comment 62

[[e-mail]]

Comment on attachment 146108 [details] [diff] [review]
Displays account name in POP3 statusbar messages v2

It might have been requested six years ago but it's actually only my eighth oldest outstanding request; better late than never, I guess...

>-      UpdateStatus(POP3_CONNECT_HOST_CONTACTED_SENDING_LOGIN_INFORMATION);
Instead of duplicating code (and failing to remove UpdateStatus) you should fix UpdateStatus to insert the account name.

>+        nsresult rv = mStringService->GetBundle(getter_AddRefs(bundle));
One good thing is that we've since switched from the weird string service to a normal bundle :-)

>+        if (bundle)
>+        {
>+            const PRUnichar *formatStrings[] = {
>+                m_accountName.get(),
>+            };
Nit: 2-space indent please.

>+        }
>       status = SendUsername();
>       break;
>+      }
If you want to keep the existing lines inside the new block then please reindent them.

>+  nsXPIDLString m_accountName;
This should be an nsString (also avoiding the include).

>-4009=Received %ld of %ld messages
>+# the %S will be replaced with the account name
>+4009=Received %ld of %ld messages for account '%S'
Ah, the days of unrestricted string changes ;-)

Comment 63

[David :Bienvenu]

I don't know if Andrew is still around - I can look at reviving the patch, if not.

Comment 64

[[e-mail]]

Comment on attachment 436699 [details] [diff] [review]
fix for imap alerts

>+5117=The current command did not succeed. The mail server for account %S responded: 
>+5118=The current operation on '%2$S' did not succeed. The mail server for account %1$S responded: 
I wonder whether these messages should have the server response as an insertion.

>+      const PRUnichar *params[] = { hostName.get(), PromiseFlatString(aString).get() };
Unsafe, sorry. Try using an nsString& temporary variable.

> NS_IMETHODIMP  nsImapIncomingServer::FEAlertFromServer(const nsACString& aString,
>                                                        nsIMsgMailNewsUrl *aUrl)
> {
>   NS_ENSURE_TRUE(!aString.IsEmpty(), NS_OK);
>-  
>+
>   nsresult rv;
>   nsCOMPtr <nsIMsgMailSession> mailSession =
>     do_GetService(NS_MSGMAILSESSION_CONTRACTID, &rv);
>   NS_ENSURE_SUCCESS(rv, rv);
Could remove this if you called nsImapIncomingServer::AlertUser instead.

>+  if (imapState == nsIImapUrl::nsImapSelectedState)
What if the very first SELECT command fails, will that count as a folder?

>+  rv = GetStringBundle();
Unused assignment to rv.

>+  nsresult AlertUser(const nsAString& aString, nsIMsgMailNewsUrl *aUrl);
static?

Comment 65

[David :Bienvenu]

(In reply to comment #64)
> I wonder whether these messages should have the server response as an
> insertion.
If you mean as a variable that the localizer can control the location of, yeah, that's a good idea. I'll do that, since I'm changing the string anyway.

> >+  if (imapState == nsIImapUrl::nsImapSelectedState)
> What if the very first SELECT command fails, will that count as a folder?

Yes, good question - it's the required state, not the current state - 
  const long nsImapSelectFolder  = 0x10000002;
    if (m_imapAction & 0x10000000)
      *aImapUrlState = nsImapSelectedState;

Comment 66

[David :Bienvenu]

Attachment: fix addressing comments - checked in

this addresses your comments, and fixes an issue where we were appending a '.' to the end of the server message, even if the server message had a '.' at the end.

Comment 67

[[e-mail]]

Comment on attachment 436782 [details] [diff] [review]
fix addressing comments - checked in

>+  message.Trim(" \t\b\r\n");
>   // Find the first word break.
>   PRInt32 pos = message.FindChar(' ');
> 
>   // Find the second word break.
>   if (pos != -1)
>     pos = message.FindChar(' ', pos + 1);
> 
>+  if (message.Last() != '.')
>+    message.Append('.');
>+
>   // Adjust the message.
>   if (pos != -1)
>+    message = Substring(message, pos + 1);
The . suffix and check seems to have been inserted at an odd place. I would feel happier if it was moved to just after the trim.

>+  NS_ConvertUTF8toUTF16 unicodeMsg(message);
Again. this is in an odd place. I came up with three alternatives:
1. Move it up just after the last use of message
2. Move it down just before the use of unicodeMsg
3. Make the message always the second insertion (%2$S) and the folder name the third insertion, even on the en-US locale.
[I found it hard to decide between the three, but I think I like #2 best]

>-  nsresult rv;
>-  rv = GetStringBundle();
>+  nsresult rv = GetStringBundle();
[Does this rv get used?]

Comment 68

[David :Bienvenu]

Comment on attachment 436782 [details] [diff] [review]
fix addressing comments - checked in

I moved the period code after the trim, and adjusted the comment.

Comment 69

[David :Bienvenu]

hmm, sorry, missed the other two comments...I'll have to think about them a little. Maybe I'll roll them into the pop3 version of the patch, or just land them as a follow-on.

Comment 70

[David :Bienvenu]

Attachment: wip for the pop strings

this converts some of the strings to include account names, and converts them to named strings instead of id strings. Need to test this some more, and tweak the suite file.

Comment 71

[David :Bienvenu]

Attachment: pop3 strings fixes

This converts the same strings as the original version of this patch. Bryan, I've gone back and forth a bit on this string, which is displayed when the download is complete:

receivedMessages=%3$S Received %1$S of %2$S messages

Now I have the account name first, which avoids the the proposition question when the account name is at the end (for/to etc.) I could change it to "Downloaded" to match the "Downloading" message, and then use the same proposition...What do you think?

Comment 72

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 437303 [details] [diff] [review]
pop3 strings fixes

Downloaded sounds best to me, I would go with that.  Everything else looks good.

Comment 73

[Nomis101]

Because I like this enhancement I've tried this POP3 patch (on Mac). But now everytime I retrieve my pop mails I see an empty warning dialog. Therefore I've made debug builds with and without this patch and compared the logs. Without the patch I see while retrieving the mails:
> Begin mail message delivery.
> End mail message delivery.
With this patch I don't see this, I see instead:
> WARNING: getting z level of unregistered window: file /Volumes/Developer/temp/src/mozilla/xpfe/appshell/src/nsWindowMediator.cpp, line 606

Comment 74

[Ludovic Hirlimann [:Usul]]

Neil why did you only grant sr+ and did nothing about the r request ?

Comment 75

[David :Bienvenu]

Comment on attachment 437303 [details] [diff] [review]
pop3 strings fixes

switch review to standard8 - I think Neil doesn't access pop3 regularly...

Comment 76

[Mark Banner (:standard8)]

Attachment: pop3 string fixes v2 - checked in.

Sorry for the delay in this. Here's the patch with bitrot fixed.

r=Standard8

Comment 79

[:aceman]

I'll check out if the patch "Displays account name in POP3 statusbar messages v2" can be revived in any way.

Comment 83

[Thomas D. (:thomas8)]

To avoid more duplicates, let's add some typical search words to the summary (unfortunately, Bugzilla doesn't have another effective way of adding alternative search words)...

Comment 84

[Matt]

forgive my ignorance,  but is this bug pending review or not?

Comment 85

[Ludovic Hirlimann [:Usul]]

It needs checking AFAICT

Comment 86

[Mark Banner (:standard8)]

I'm not sure of the status here, maybe aceman can help.

Comment 87

[:aceman]

I think we fixed this for POP3 alert dialogs in bug 221592.
This still needs to be checked what is the situation on IMAP (bug 214854) and other accounts.
The status bar still does not show the account name. Maybe we could revive the existing patch. There are only small nits from Neil to be addressed.

I think some of the remaining chunks of work could be split into separate bugs as this one is getting long. And this one could be work as a meta bug since now.

Suyash, as you have great experience with the string displaying functions from 221592, can you look at this?

Comment 88

[Suyash Agarwal (:sshagarwal)]

Sure.
Since this depends on bug 214854, fixing that one first.

Thanks.

Comment 89

[:aceman]

There are already enough comments here. I have split some of the remaining work to other bugs (reopened some of the dupes that actually request only part of the functionality). Let's keep this as a meta bug.

And mark that the hero doing all this work is Suyash :)

Comment 90

[Ludovic Hirlimann [:Usul]]

Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.

Comment 91

[Simon Crowder]

I support the request for [account name] in status bar messages, and since this report is meta I'll add the following suggestion / wish: 

Make 'Activity Manager' window dockable to main window.

Comment 92

[Thomas D. (:thomas8)]

This bug has been converted into a meta bug per comment 89, let's add that to the summary, too, for clarity. The current assignment has been set to reflect and honor that much of the relevant work has been done by Suyash. The current assignment does NOT indicate that somebody is assigned to the remaining parts / dependants of this bug.
Assignments to Meta bugs are a bit unusual and might misleadingly suggest that everything is being worked on; Aceman, maybe we can remove the current assignment?

Significantly, we're still not showing account names for some of the basic use cases which can actually take long on big mail boxes and/or slow connections, so it would be most helpful to know the account name:

IMAP: "Downloading 1 of 10 in Inbox" -> This should become: "[Account name]: Downloading message 1 of 10 in Inbox…"
POP: "checking Inbox for new messages" -> This should become: "[Account name]: Checking Inbox for new messages…"

If we don't have bugs for those yet, they should be filed as "Good first bug" with language attributes in Whiteboard.

Comment 93

[Thomas D. (:thomas8)]

(In reply to Simon Crowder from comment #91)
> I support the request for [account name] in status bar messages, and since
> this report is meta I'll add the following suggestion / wish: 
> 
> Make 'Activity Manager' window dockable to main window.

Simon, thanks for that nice idea. It's already filed as bug 532646; however, it hasn't received any interest or support yet. Given manpower limitations, we probably won't dedicate our main developers time to this in the foreseeable future, but we'd certainly accept a patch - can you help? I've added some more comments and ideas on bug 532646, e.g. making Activity Manager accessible from Status bar.

Comment 94

[Thomas D. (:thomas8)]

Adjust summary to be more generic; keep bulky summary details as unfortunately it's the only way of having relevant search words for easy retrievability of this bug and avoiding more duplicates.

Comment 95

[Thomas D. (:thomas8)]

I've also just seen a message "3 messages downloaded" and I couldn't even tell for which account or account type that occured (mixed account types). Can we please try to add the account name for all such status bar messages?

Comment 96

[Thomas D. (:thomas8)]

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #92)
> IMAP: "Downloading 1 of 10 in Inbox" -> This should become: "[Account name]:
> Downloading message 1 of 10 in Inbox…"

Filed as bug 1348762.

> POP: "checking Inbox for new messages" -> This should become: "[Account
> name]: Checking Inbox for new messages…"

Filed as bug 1348769.

Comment 97

[Charles]

So... should my bug 644713 be added to this one? I think so, but not sure...

Comment 98

[Thomas D. (:thomas8)]

Thank you Charles for following up!

In reply to Charles from comment 97:
> So... should my bug 644713 be added to this one? I think so, but not sure...

I think so, too. It does make sense to know between which accounts messages are being copied, as user can start multiple copying operations involving different accounts. It's important to know which one is finished or not.

Comment 99

[:aceman]

Comment on attachment 146108 [details] [diff] [review]
Displays account name in POP3 statusbar messages v2

I think this one is obsoleted by the other POP3 patch.

Comment 100

[:aceman]

I would love if the prepending of the account name could be done in some generic way in a helper function. Otherwise the amount of code needed in C++ to do it awful.

In this bug the possible optimizations/merging could be analysed.
I have proposed some options in bug 689992 comment 15, but it seems they are not as easy per bug 689992 comment 16.

Comment 102

[Bill Dietrich]

Never going to be fixed ? I came to file a feature request that TB should specify server / account name in error/status messages such as "can not contact IMAP server, maybe you have too many threads active", and found this issue open for 20 years now. Still unfixed in TB 84.0b1 !

Comment 103

[Wayne Mery (:wsmwk)]

(In reply to Bill Dietrich from comment #102)

Never going to be fixed ? ... Still unfixed in TB 84.0b1 !

This has been labeled a meta bug. This means the work of fixing occurs in other bug reports, like bug 161279.

I came to file a feature request that TB should specify server / account name in error/status messages such as "can not contact IMAP server, maybe you have too many threads active", and found this issue open for 20 years now.

What you want is bug 161279.

Comment 104

[Wayne Mery (:wsmwk)]

Ping, do you know if this is resolved on the pop side with the rewrite?

Comment 105

[Ping Chen [:rnons] (away)]

No, the rewrite didn't change any status or error message.