586729 - Quickfilterbar search lost "swap Sender vs. Recipients magic" for Inbox vs. Sent style folders

Status: NEW

(Thunderbird :: Search, defect)

Description

[Thomas D. (:thomas8)]

STR

0 You are looking for mails involving another person called "FooSender" that's not you

1 some INBOX-type folder, quick filter bar: type "FooSender" into the box, and switch off Recipient criterion (so you have only Subject and Sender enabled)

2 optionally, turn on sticky mode (Keep filters applied when switching folders), which will spare you from typing FooSender again in step 3

3 from folder pane, select a SENT-style folder

Actual Result

- search criteria for sent folder are still the same:
-> will search for "FooSender" (your friend) in Subject or Sender
-> no results for most cases, as the Sender in Sent is always me, so there's not much to look for in the sender field
- Actually, with sticky mode on it makes even less sense as we carry forward the "FooSender" (my friend) from an inbox folder which will almost NEVER be the sender (me) in Sent folders

Expected

- if "Recipients" criterion is disabled when switching from INBOX-style to SENT-Folder,
-> Recipients criterion should be turned on (checked=true)
-> Sender criterion shoul be switched off (checked=false)
-> will search for "FooSender" in Sent folder's "Recipients" column
-> will find messages I sent to "FooSender" (which is what I want, in 98% of cases)

iow,
- if either Sender or Recipients criterion has been UNchecked (on secondary filter bar)
- when switching from inbox-style to sent-style folder or vice versa
-> swap Sender and Recipients criterion (swap their "checked" state)

This Sender vs. Recipient magic used to work in TB2 (although the UI doesn't reflect it correctly!), probably 3.0 as well, and most likely got lost with the introduction of new Quick Filter Bar in TB 3.1.
-> regression

Needless to say this will be highly annoying for folks who happen to use that sort of filter and hop around between folders, as they will have to click two buttons every time they change folders...

Comment 3

[Thomas D. (:thomas8)]

http://gsfn.us/t/19uyv

Comment 4

[Eliot Lear]

First, I don't understand the difference between this bug that you've created and the original Bug 566307 that you have not marked as a duplicate.  Second, I would appreciate keeping the discussion here and NOT in the URL contained in Comment 3 for a number of reasons, the least of which is that your OpenID function is broken, and not the least of which is that BugZilla seems like a good place to discuss TB bugs.

Comment 5

[Thomas D. (:thomas8)]

(In reply to comment #4)
> First, I don't understand the difference between this bug that you've created
> and the original Bug 566307 that you have not marked as a duplicate.

Fair enough. There is a difference: Bug 566307, as per the current summary, wants that "Quickfilterbar's search criteria/sub-filters (sender, recipients, ...) should be remembered *per folder*". So each folder and subfolder would have its own set of filter criteria memorized. That's probably too much, and too much work, not sure if this would really help. On the other hand, this bug 586729 only differentiates between *two types* of folder: Inbox-style and Sent-style folders. That's a lot easier to handle (code-wise), and will address the biggest problem underlying bug 566307. Therefore, I DID mark 566307 as a duplicate of this one. I hope that's ok with you.

> Second, I would appreciate keeping the discussion here and NOT in the URL 
> contained in Comment 3

I only added the link to the getsatisfaction report as a point of reference, not to move the discussion there. In this particular case, there won't be much discussion I hope, as it's a regression and there's good arguments in favour. Albeit even good arguments don't always help, due to the human factor...

> for a number of reasons the least of which is that your OpenID
> function is broken,

...then that's likely to be a problem of Getsatisfaction service that MozillaMessaging uses. You should file a bug against the GetSatisfaction Product at http://getsatisfaction.com/getsatisfaction

Comment 6

[Eliot Lear]

Thanks very much for the explanation.  I think I could argue the technical solution both ways, but I certainly could see that more code could be required, since it doesn't strike me that this would be something you would hide in prefs and equally seems inappropriate for an index file.  The argument on the other side is that meta-information about a folder may be useful in other contexts, and there already is at least some (see Folder Properties).  Where is that stuff stored?

Comment 7

[Andrew Sutherland [:asuth] (he/him)]

This should be pretty straightforward to fix and test as long as we cause the change in semantics to be something we invert on UI display, UI mutation, and search creation only in outgoing folders.  Which is to say, we want the UI to display that the change, but we don't want to actually mutate the underlying state during the transition between folders.  Otherwise we start getting more complexity when the user opens a new tab and we inherit the changes or anything else that persists/propagates state.  Testing is easier without that hassle.

Comment 9

[mitch deoudes]

Just chiming in to say that I believe this worked the "correct" way in TB 2.0.  That is, when you were in Sent and hit ctrl-F, the resulting filter box was "Subject and To", whereas in other folders it defaulted to "Subject and Sender".  I think it even remembered if you forcibly changed it to something else.  Don't have an installed TB 2.0 to check right now, but my memory is that it was pretty much always doing what you wanted.

Also, another instance where it's important to know the Sent folder addressing logic is backwards from other folders:  auto-selection of "From" address for replies.  My point being that Commenter #6 above is correct in saying this is not just a single special case.

(See http://forums.mozillazine.org/viewtopic.php?f=31&t=2047079 for an explanation of that issue.)

Comment 10

[Andrew Sutherland [:asuth] (he/him)]

Attachment: abandoned patch to fix this problem; has debug dumps in it, no test

I started on a patch for this some time ago; it never actually reached the operational stage, though.  (I became a bit concerned by the complexity required to actually do it correctly and some other higher priorities intervened.)