Closed Bug 297251 Opened 15 years ago Closed Last month

[advanced search] Search Messages resets the sort order / sort column. column choices and order should persist

Categories

(Thunderbird :: Search, defect)

x86
All
defect
Not set

Tracking

(blocking-thunderbird3.1 -, thunderbird_esr6868+ fixed, thunderbird69 fixed, thunderbird70 fixed)

VERIFIED FIXED
Thunderbird 70.0
Tracking Status
blocking-thunderbird3.1 --- -
thunderbird_esr68 68+ fixed
thunderbird69 --- fixed
thunderbird70 --- fixed

People

(Reporter: sspitzer, Assigned: alta88)

References

()

Details

Attachments

(2 files, 2 obsolete files)

[advanced search] searching resets the sort order / sort column

to reproduce:

do an advanced search that returns multiple results.  (I did body contains on a
local folder)

the results appear in date ascending.

change the sort (either date descending or click on another column)

click the search button again and we will revert to date ascending.
I'm using tbird version 1.0+ (20050604) on windows xp
Severity: normal → minor
is "ignores" sort column is a better descriptor than "resets"?  sort indicator is always shown on the last column selected, regardless of the results.  

advanced search results are always returned as article physical order in the datasource - which is not unreasonable given that the (partial) results are displayed as the search progresses through the source. This is even more evident when searching multiple folders with folder name column displayed.

Are you suggesting that sort order indicator be removed after each search results? Or, are you suggesting a different display result, requiring perhaps more fundamental changes?
QA Contact: front-end
Seth, comment 2 :)
Assignee: mscott → nobody
Hi, I came up with this bug doing a search for my problem. I have successfully migrated from Outlook at work, moving 2 years worth of emails to Thunderbird specifically because of Outlook's poor search features. My problem is that when I search for something in Thunderbird, all the messages come up starting with 2007 - which in 99% of the cases means I am searching starting from the least relevant results, and I have to wait about 5 minutes to get to 2009, which is ridiculous when searching for an ftp password I was mailed 3 weeks ago... I have a feeling this would not be difficult to change in Thunderbird? Or am I missing some very easy solution?

Thanks!
Flags: wanted-thunderbird3?
So, what I am actually requesting is that the search order is either reversed or customizable :)
(In reply to comment #5)
> So, what I am actually requesting is that the search order is either reversed
> or customizable :)

This bug isn't what you want - you want the search to actually happen in reverse order, looking at newest messages first. This bug is about the order that we display the results, not the order that we calculate them.

for local searches, as opposed to imap, we could probably do this. For IMAP, we're somewhat dependent on what the imap server does.
Really fast reply, thank you.

I am talking about a  local search.

Should I file a separate feature request then?
yes, thx.
Duplicate of this bug: 533286
Duplicate of this bug: 439697
Flags: wanted-thunderbird3? → blocking-thunderbird3.1?
Not blocking 3.1 on this as it doesn't seem a big user issue.
blocking-thunderbird3.1: --- → -
Flags: blocking-thunderbird3.1? → wanted-thunderbird+
Duplicate of this bug: 473598
See Also: → 528044
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 260289
sorry for spam - I failed to examine component of this bug against bug 260289 :(
Severity: minor → normal
Status: RESOLVED → REOPENED
Component: Mail Window Front End → Search
QA Contact: front-end → search
Resolution: DUPLICATE → ---
See Also: → 260289
Duplicate of this bug: 648851
This does not appear to me to be a dup of 260289, which is specific to the address book.

I think I've got the same problem.  In my case, I think it has to do with secondary sort.  

It didn't used to be this way!  This used to happen in 3.<something> timeframe, but it was fixed somewhere along the way; did not happen, for example, in 9.x (and I don't think in 8.x).  It's now back with either 10.0 or 10.0.1, and it continues in 10.0.2.  

I'm currently running 10.0.2.  I experience this issue in unified folders and in saved search folders.  My mailnews.default_sort_order is 2 and mailnews.default_sort_type is 18 (descending byDate).  On some folders, I have a secondary sort to bring flagged (starred) items to the top (starred by descending date, then everything else by descending date).  

**For those folders with a secondary sort:**

When I performing a quick filter, the order for the results is something I can't quite figure out (doesn't always have a recognizable pattern, but it is sometimes date ascending) -- I would expect it not to change the sort at all from the original folder's display (starred by desc date then desc date).  The secondary sort is usually followed (so I get starred items in random order, then everything else in random order).  

So the results seem to ignore the primary sort and the default sort, but they pick up the secondary sort.  

I would think that the folder has one sort, no matter if quick filter is applied or not, so that if you do not change the sort under quick filter, the original does not change; and if you DO change the sort under quick filter, the original DOES change.  But that's not what I am experiencing.  

Sometimes (but not usually), performing a quick filter changes the sort of the original folder (when I do not change any sorts).  I haven't been able to determine a pattern.

Sometimes (but not always), if I change the sort order while in the middle of a quick filter, the original folder is also changed.  I haven't been able to determine a pattern.  

I haven't (yet?) experienced the problem on a folder with simple sort (which matches the default, desc byDate), so in my case, the issue is with sorting of quick filter results on folder that have a secondary sort.

-- mdeck
p.s. I'm on Win 7 64-bit.
See Also: → 421335
Summary: [advanced search] searching resets the sort order / sort column → [advanced search] Search Messages resets the sort order / sort column. column choices and order should persist

possible to do here what squib did in bug 528044 ?

Flags: needinfo?(acelists)
OS: Windows XP → All
Duplicate of this bug: 374551
Duplicate of this bug: 1300415
Duplicate of this bug: 1476117
Duplicate of this bug: 737093
Blocks: 522861
Attached patch searchCols.patch (obsolete) — Splinter Review
  1. share threadTree in an inc file for search access to all columns.
  2. make user's column selection and sort order persistent for search.
  3. remove some dead attributes from threadTree.

this depends on Bug 545906 changes else it won't apply.

Assignee: nobody → alta88
Attachment #9081980 - Flags: review?(richard.marti)
Attachment #9081980 - Flags: review?(acelists)
Depends on: 545906
Comment on attachment 9081980 [details] [diff] [review]
searchCols.patch

Review of attachment 9081980 [details] [diff] [review]:
-----------------------------------------------------------------

::: mail/base/content/threadTree.inc.xul
@@ +29,5 @@
> +                                 fixed="true"
> +                                 cycler="true"
> +                                 currentView="unthreaded"
> +#ifdef SEARCH_WINDOW
> +                                 <!-- The search view does not support threading. -->

This comment inside the element breaks the search window with a malformed error.
Attachment #9081980 - Flags: review?(richard.marti) → review-
Attached patch searchCols.patch (obsolete) — Splinter Review
Attachment #9081980 - Attachment is obsolete: true
Attachment #9081980 - Flags: review?(acelists)
Attachment #9082857 - Flags: review?(richard.marti)
Attachment #9082857 - Flags: review?(acelists)
Comment on attachment 9082857 [details] [diff] [review]
searchCols.patch

Review of attachment 9082857 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks, looks good and works. r+ with the comment addressed.

::: mail/base/content/SearchDialog.xul
@@ +12,5 @@
>  <?xml-stylesheet href="chrome://messenger/skin/folderMenus.css" type="text/css"?>
>  
>  <!DOCTYPE window [
> +  <!ENTITY % messengerDTD SYSTEM "chrome://messenger/locale/messenger.dtd" >
> +  %messengerDTD;

Now with the messenger.dtd added, the strings for the columns are doubled. You can now remove them from SerchDialog.dtd.
Attachment #9082857 - Flags: review?(richard.marti) → review+
Attached patch searchCols.patchSplinter Review

ah right, removed dupe strings; there's some other bug about it. anyway, if aceman has any substantive comments, i'll do them in a followup. one r+ is enough here.

Attachment #9082857 - Attachment is obsolete: true
Attachment #9082857 - Flags: review?(acelists)
Flags: needinfo?(acelists)
Attachment #9082894 - Flags: review+
Keywords: checkin-needed
Comment on attachment 9082894 [details] [diff] [review]
searchCols.patch

Review of attachment 9082894 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks, this looks good to me. I thought that the column selection is now shared between the main thread pane and the search window, but that is not the case.

::: mail/base/content/SearchDialog.js
@@ -240,5 @@
>  
> -  gFolderDisplay.setColumnStates({
> -    subjectCol: { visible: true },
> -    correspondentCol: { visible: Services.prefs.getBoolPref("mail.threadpane.use_correspondents") },
> -    senderCol: { visible: !Services.prefs.getBoolPref("mail.threadpane.use_correspondents") },

Is this solved in the Search dialog with some other code now? Or is it done by the automatic restoration of columns and this code was only needed when we always initialized the search columns from scratch?
Attachment #9082894 - Flags: review+

(In reply to :aceman from comment #32)

Comment on attachment 9082894 [details] [diff] [review]
searchCols.patch

Review of attachment 9082894 [details] [diff] [review]:

Thanks, this looks good to me. I thought that the column selection is now
shared between the main thread pane and the search window, but that is not
the case.

No, and it shouldn't be. In fact, it can't be since in threadpane the column selection is folder specific and stored in the .msf db.

::: mail/base/content/SearchDialog.js
@@ -240,5 @@

  • gFolderDisplay.setColumnStates({
  • subjectCol: { visible: true },
  • correspondentCol: { visible: Services.prefs.getBoolPref("mail.threadpane.use_correspondents") },
  • senderCol: { visible: !Services.prefs.getBoolPref("mail.threadpane.use_correspondents") },

Is this solved in the Search dialog with some other code now? Or is it done
by the automatic restoration of columns and this code was only needed when
we always initialized the search columns from scratch?

The search dialog column selection and sort is restored based on persisted dom attributes (used to be xulStore.json but now is in xulStore/data.mdb), since there's no backing db, as there is for folders in threadpane.

Btw, someone should do the same dedupe for the addressbook list and search, along with making those colpickers sticky.

Something we should backport? Looks like an old bug.

Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/f6e91a51bd51
Persist search dialog list column choice and sort column/order; share threadTree between 3pane and search. r=aceman

Status: REOPENED → RESOLVED
Closed: 9 years agoLast month
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 70.0

Bug 545906 also got the ESR approval. And it makes sense to backport. The string changes are only removals, so no problem.

Attachment #9082944 - Flags: approval-comm-esr68?
Comment on attachment 9082944 [details] [diff] [review]
searchCols-beta-ESR.patch

Bug 545906 hasn't been approved yet. It's a bit tricky since it has an M-C part. Should this thing here go through a beta first?
Attachment #9082944 - Flags: approval-comm-beta+

Appears to be working in the beta.

Status: RESOLVED → VERIFIED
Attachment #9082944 - Flags: approval-comm-esr68? → approval-comm-esr68+
Comment on attachment 9082944 [details] [diff] [review]
searchCols-beta-ESR.patch

Doesn't apply due to the closemenu="none" stuff which isn't on beta, but is on trunk and esr68.
Attachment #9082944 - Flags: approval-comm-esr68+

Also working in TB 68 ESR.

Regressions: 1577987
You need to log in before you can comment on or make changes to this bug.