503858 - "Account" thread-pane column for smart folders is blank for messages in IMAP accounts

Status: RESOLVED DUPLICATE of bug 448568

(MailNews Core :: Networking: IMAP, defect)

Description

[M.J.G.]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.1) Gecko/20090630 Fedora/3.5-1.fc11 Firefox/3.5
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1pre) Gecko/20090712 Lightning/1.0pre Shredder/3.0b3pre

For POP messages, the variable m_accountKey (resp. mAccountKey) is set from  the "X-Account-Key" header (HEADER_X_MOZILLA_ACCOUNT_KEY), and this used for for the "account" column in the message list.

For IMAP messages this info is empty.

This is troublesome when virtual safed searches or smart folders are used because, for example, every Inbox is simply named Inbox.

I suggest either filling in that info in the IMAP sink, or changing the UI code to look for the account info in a different place.

Reproducible: Always

Steps to Reproduce:
1. Set up saved search or use smart folders' Inbox spanning several IMAP accounts
2. Display (activate) the account column in the message list pane
3.
Actual Results:  
Account column is empty for IMAP messages

Expected Results:  
Account column shows account

I know this is the current design, so it's not a bug per se but a huge usability drawback for the newer features (saved search, smart folders) which should be used more extensively now that gloda makes them fast.

[I also wish there was an "IMAP backend" component in BZ.]

Comment 1

[Joshua Cranmer [:jcranmer]]

There is, you're just not looking hard enough.

Comment 2

[M.J.G.]

(In reply to comment #1)
> There is, you're just not looking hard enough.

If, by that cryptic comment, you mean there is an IMAP component: There is definitely none in the new bug page for Thunderbird. Who would think that that page's list differs from the one for an existing bug?

Comment 3

[Delphine Ménard]

User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3


I confirm this behaviour, which pretty much render virtual accounts useless. 

See screenshot.

Comment 4

[Delphine Ménard]

Attachment: Screenshot of empty account column.

Comment 5

[M.J.G.]

Changed to "normal bug" rather than enhancement because an empty account column is certainly a bug (beyond the fact that it renders smart folders useless), not a missing feature.

Comment 6

[M.J.G.]

Bug has been confirmed independently from the reporter.
I can confirm it's present in Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090925 Lightning/1.0pre Shredder/3.0pre.

Can someone change to "confirmed" please? My only options are "unconfirmed" and "resolved".

Comment 7

[Nikolay Shopik]

Empty account column for IMAP
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20090923 Shredder/3.0pre

Comment 8

[Nikolay Shopik]

Ludo, smartfolders now is default representation in TB3 and this bug could be blocker for release what you think?

Comment 9

[Ludovic Hirlimann [:Usul]]

This looks like bug 457304 ? or is kind of similar shall we dup them ?

Comment 10

[M.J.G.]

(In reply to comment #9)
> This looks like bug 457304 ? or is kind of similar shall we dup them ?

That bug is about identifying Sender or Recipient by looking them up in the address book.

This one here is about identifying the account in which a message is stored. We already have "Location" working which displays the (deepest level) folder. "Account" is supposed to be the account name. "Location" is "Inbox" for all inboxes, which is why the additional account column is need to distinguish them.

Comment 12

[David :Bienvenu]

we want this, but we won't block 3.0 for this.

Comment 13

[David]

I can confirm this bug:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091112 Shredder/3.0pre

Comment 15

[Christian Kuehn]

I also confirm it in the release:

Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0

Comment 16

[Mark Banner (:standard8)]

@lujomu please be careful not to remove flags from bugs, they are required for tracking purposes.

Comment 17

[Mark Banner (:standard8)]

This has actually been fixed by bug 448568.