612800 - Not all tags displayed when switch between unread and not on quick filter bar (tag bar doesn't refresh on condition changes)

Status: RESOLVED DUPLICATE of bug 1830439

(Thunderbird :: Search, defect)

Description

[Speedo Goo]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.12 (KHTML, like Gecko) Chrome/9.0.576.0 Safari/534.12
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20101116 Thunderbird/3.3a1pre

Suppose I have 2 tags defined: A, B. I have existing mails tagged with both A and B, but there is no unread mails tagged A. Now when I toggle between unread and not on the quick filter bar, tags labels are not displayed correctly.

Reproducible: Always

Steps to Reproduce:
Suppose there are 2 mails in a folder: mail #1 tagged A, is read; mail #2 tagged B, is unread

1. Click unread, only #2 is shown
2. Click tags, still #2 shown, the tags bar (below quick filter) shows B
3. Click unread, #1 and #2 shown, the tags bar still only shows B
4. Click tags, now no quick filter applied, #1 and #2 shown
5. Click tags, the tags bar shows A and B, #1 and #2 shown in message list
6. Click unread, tags bar still shows A and B, but only #2 in message list

The step 3 above is definitely a bug, because tags bar should also display A. Step 6 might also be a bug, because there is no messages tagged A in the message list (and from step 2 and 3, it seems Thunderbird only displays tags that mails in message list are tagged with).
Actual Results:  
See above

Expected Results:  
At step 3, tags bar should display A and B.
At step 6, tags bar should display B.

Comment 1

[Ludovic Hirlimann [:Usul]]

Does this happens also in -safe-mode ?

Comment 2

[Speedo Goo]

> Does this happens also in -safe-mode ?

Yes.

Comment 3

[Ludovic Hirlimann [:Usul]]

Is this on Local folders or imap folders ?

Comment 4

[Speedo Goo]

Both. I first noticed this on IMAP, and then in order to file this report, reproduce it on a local folder.

Comment 5

[Ludovic Hirlimann [:Usul]]

I was unable to reproduce, can you guys reproduce ?

Comment 6

[Wayne Mery (:wsmwk)]

I couldn't repro with trunk build but my brain is fried today. I'd better trust rsx11m results than mine :)

Comment 7

[rsx11m]

Sure. easy to reproduce in today's Windows nightly build with the given steps.

The issue is that the tag bar which appears when you restrict to tagged-only messages reflects the displayed tags at the time you enable it. For example, having a unread mail tagged with "Work" and a read mail with "Personal" will
show "Work" only as orange text in that bar. If you remove the unread-only restriction (step #3), the green-tagged message shows up in the list now, but the tags bar still only shows "Work" where it should read "Work Personal".

Thus, the tag bar needs to be refreshed whenever other conditions change.
Tentatively confirming, assuming you've already searched for duplicates.

Comment 8

[Thomas D. (:thomas8)]

omg, tag filtering is ultimate confusion, and so buggy!!!

The confusion parts need a new bug, so here are the buggy parts (reduced testcases for this bug)

Testcase 1:

STR

1) Pop3 local folder with the following messages (make subjects identical with tags, to see the bug better; i'm using *starred* instead of *unread* because unread is more volatile and thus more confusing; also works with any other conditions from the main quickfillter bar)

msg 1: starred 
msg 2: starred + tagged 'todo'
msg 3: (not starred), tagged 'important' and 'personal'
msg 4: (not starred, not tagged)

2) Let's filter:

a) quickfiter for 'must be starred'
-> returns msgs 1 and 2 (ok)

b) add quickfilter for 'must have tags'
-> returns msg 2 only (ok)
-> lists all tags that actually occur on result messages: 'todo' tag only (ok)

c) remove quickfilter for 'must be starred' (thus remain with quickfilter for 'must have tags' only)
-> returns msgs 2 and 3 (ok)
-> *does not* list all tags occuring on result messages: 'todo' tag only (wrong, should be 'todo', 'important', and 'personal')

3) realize the dataloss danger (esp. for large result sets)
- normally, on the tag bar, TB will show *all* the tags that occur on any of the result set messages (ux-feedback)
- thus, according to ux-feedback, a tag that does *not* occur on the tag bar should *not* be present on any of the result messages
- thus, with TB showing only 'todo' tag in 2c) above, (and *not* showing 'important' or 'personal' tag, this bug), user can safely assume there are no messages in the result set that have 'important' or 'personal' tags
- thus, based on ux-feedback, user can easily delete all result set messages in good faith
-> dataloss, user unintentionally deleted messages that are tagged 'important' and 'personal', due to wrong ux-feedback: this bug!
(And if your intention was to only keep messages tagged 'personal' you will not even get the color feedback in the result list, so there is no indication whatsoever that 'personal' messages are in the result set unless you view them individually)

*************************
Testcase 2:

STR:

1) Folder with these messages (see comments above)

msg 1: starred 
msg 2: starred + tagged 'todo'

2) Let's filter:

a) quickfiter for 'must be starred'
-> returns msgs 1 and 2 (ok)

b) add quickfilter for 'must have tags'
-> returns msg 2 only (ok)
-> lists all tags that actually occur on result messages: 'todo' tag only (ok)

c) for msg2, add the tags: 'important' and 'personal'
-> tag bar is not updated, still only showing 'todo' (but should show all tags that are present on result messages, including 'important' and 'personal' which are missing!)

3) realize the 'dead end'
- from a larger result set, try narrowing down your current quickfilter on messages that you have just tagged 'important' and 'personal' from within the result set
-> realize you cannot act on the newly-set tags unless you remove the main tagfilter and tagfilter again! (ggrrr)

This bug violates ux-feedback, ux-consistency, and ux-error-prevention (at least); wrong ux-feedback about search results is a serious offence, and datalossy, so surely not minor! (imo, this is major)

Comment 9

[Thomas D. (:thomas8)]

And I'm sure I posted a comment about this wrong behaviour in the very first days when qfb was introduced...

Comment 10

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #9)
> And I'm sure I posted a comment about this wrong behaviour in the very first
> days when qfb was introduced...

That was Bug 545955 Comment 13 following, similar to this bug. However, Bug 545955 Comment 13 is solved (but I don't think the tag bar scalability issues of Bug 545955 Comment 14 and 15 have been solved, or have they?).

Comment 11

[Mihovil Stanic [:Mikeyy - L10n HR]]

TB 11

When using quick filter bar press:

1. Unread
2. Tag 

Now TB is showing all unread mails which are tagged. Row bellow quick filter bar contains all tag labels. To this point this is all working as it should.

3. Press Unread button again to show all mail, not only unread.

Now you see all mail which is tagged, it doesn't matter if it's read or unread.
Problem is that line bellow quick filter bar which is containing tag labels is showing only those labels which were there when UNREAD button was ON.

Example in attachment.

Comment 12

[Mihovil Stanic [:Mikeyy - L10n HR]]

Attachment: Example of bug in quick filter bar

Comment 13

[Thomas D. (:thomas8)]

This looks related to bug 570313.

Comment 14

[Thomas D. (:thomas8)]

I've refiled this as bug 1830439, still happening in Daily 114.0a1 (2023-04-25) (64-bit), Win10.