132362 - Quick Search: Once column sort indicator points down, it is always down

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Address Book & Contacts, defect)

Description

[Ninoschka Baca]

Trunk build 2002-03-20: WinMe, Linux RH 7.1, 

Overview: Perform a quick search, click onto a column so the sort indicator 
points down, then click on the column again and the indicator remains pointed 
down.

Steps to reproduce:
1. Perform a quick search so multiple results appear
2. Click onto a column until the sort indicator shows that it's pointing down 
(aka arrow points down)
3. Click onto the same column

Actual Results:
- The arrow still points down (ascending) although the results have resorted 
into descending order.

Expected Results: 
- The arrow should point up (descending) so that it corresponds with the results 
that are displayed.

Comment 1

[Ninoschka Baca]

The problem also occurs on Mac 10.1.3.

Comment 2

[Ninoschka Baca]

Marking nsbeta1 because it can be confusing to see the sort indicator not change 
when in fact the data has been resorted.

Comment 3

[Ninoschka Baca]

Marking nsbeta1 so that Quick Search column indicators reflect reality.

Comment 4

[Mike Fedyk]

wfm: Not happening on debian linux build 20021210

Comment 5

[Ninoschka Baca]

Trunk build 2002-12-23: Mac 10.1.3, Win2k
Trunk build 2002-12-20: Linux RH 8.0
I still see the problem. 

Comment 6

[jglick]

This is working for me for Mail, 2002121608 windows build.
But Address Book is NOT working. Not only do the arrows not flip, but the data
does not reverse sort either.

Comment 7

[Ninoschka Baca]

This has regressed. In Netscape 7.01 after performing a quick search and then
clicking on a column, click on the column again to resort and the data sort
order atleast changed.

Comment 8

[Samir Gehani]

Mail triage team: nsbeta1+/adt2

Comment 9

[Cavin Song]

Reassigning.

Comment 10

[shliang]

Attachment: patch

the regression wasn't actually a regression - i think it was just an accident
that it worked in the first place (the fix to bug 177177 was what made the sort
appear to stop working)

Comment 11

[Cavin Song]

Comment on attachment 114262 [details] [diff] [review]
patch

r=cavin.

Comment 12

[(not reading, please use [e-mail] instead)]

note, this works if we aren't doing a quick search, and doesn't work if we are
doing quick search.

I have a theory (I haven't debugged yet) to why this is.

we want it so when you switch back and forth between addressbooks, or when you
exit and restart, we return the desired sort column and direction.

the code is trying to accomplish this by saving and restoring the sortColumn and
sortDirection on the element with that matches the URI.

so for the addressbook dialog, that's a treeitem in the left pane.

but the code I wrote does:

document.getElementById(gAbView.URI);

the problem is that when you do QS on the PAB for "foo", the gAbView.URI is no
longer:

"moz-abmdbdirectory://abook.mab"

but it's:

"moz-abmdbdirectory://abook.mab?(or(PrimaryEmail,c,foo)(DisplayName,c,foo)(FirstName,c,foo)(LastName,c,foo))"

so we won't find that element when we call document.getElementById()

this is a big flaw in the code I wrote.  curses! 

it would explain a bunch of problems with QS (editing cards, mailing lists, dnd,
printing, etc), but it should be easy to fix.

first, look for all callers to gAbView.URI and GetAbViewURI() and see if what
they are expecting is the the addressbook (or mailing list) URI, or the search URI?

I took a quick look and I think the only one that may really want the search URI
is the caller in ChangeDirectoryByURI().  I haven't checked, but it looks like
it really wants the search URI, which is how clicking on a addressbook in the
dir tree clears a quick search.  (let me know if that's not clear)

let's talk tomorrow about the way to clean up this code.

don't forget about the select address dialog and the addressbook sidebar panel

Comment 13

[(not reading, please use [e-mail] instead)]

Comment on attachment 114262 [details] [diff] [review]
patch

rejecting, I'll talk to shuehan tomorrow about the complete fix.

Comment 14

[(not reading, please use [e-mail] instead)]

shuehan and I talked it over, and we figured out a plan for how to fix it, and 
how to comment the code to prevent future confusion.

Comment 15

[shliang]

Attachment: patch

fixing the abview uri problem

Comment 16

[(not reading, please use [e-mail] instead)]

Comment on attachment 115156 [details] [diff] [review]
patch

clearing the review request.

shuehan has another patch that changes all this, so I'll wait for the combined
patch before reviewing.

Comment 17

[shliang]

the fix for #135877 has the fix for this.

Comment 18

[shliang]

marking fixed.

Comment 19

[Ninoschka Baca]

Trunk build 2003-03-03: WinXP, Linux RH 8
Verified Fixed. 

After performing a Quick Search, the arrow flips and the data flips each time a
column is selected. The same is true if a quick search is not performed.