425619 - JS sortable columns aren't persistent

Status: RESOLVED WONTFIX

(bugzilla.mozilla.org :: General, defect)

Description

[Bradley Baetz (:bbaetz)]

When using server-side sorting, the sort order is persistent (via a cookie). This doesn't happen with the bmo client-side sort. (This is a bmo-specific change)

Comment 1

[Jesse Ruderman]

This is an improvement, IMO.  Bugzilla's previous behavior of always remembering your last sort order was annoying.  (I usually want and expect lists to sorted by bug number, but sometimes I want to sort a specific list.)

Comment 2

[Bradley Baetz (:bbaetz)]

You can override that by choosing 'sort results by bug #' in query.cgi, then checking 'and remember these as my default search options'. I could do the same; I guess it comes down to what 'last time' means in the default option (use same order as last time)

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

Where this hits me the most is in the following scenario:

 - do a query
 - sort the resulting list by some criteria
 - click on the first bug
 - click on "next"

When the sort order got persisted to a cookie, the next/previous buttons would iterate through the list based on my selected sort criteria. Now sorting is useful in the list view, but ends up not helping me when it's time to flip through that buglist.

I'm not a common use case, so I'd say this is low priority, but it *is* a pain in the ass ;)

Comment 4

[Bradley Baetz (:bbaetz)]

Thats separate (but related); the bug list cookie needs to be updated as well. Except thats actually stored in the DB now, isn't it? Fun....

Comment 5

[Dave Miller [:justdave]]

(In reply to comment #4)
> Except thats actually stored in the DB now, isn't it? Fun....

Actually, it's not.  That got backed out.

Comment 6

[Frédéric Buclin]

(In reply to comment #1)
> This is an improvement, IMO.

This is not an improvement at all, IMO. I clicked a tinyurl on wiki.m.o about P1/P2 bugs for Fx3, which used the priority as sort order. Now all my saved searches are sorted against the priority, and clicking the bug ID header to restore my prefered sort order is not persistent anymore. That's really irritating. I had to manually append &order=bugs.bug_id to the URL to force the cookie to be restored.

Comment 7

[Jesse Ruderman]

That scenario should be fixed by not remembering sort orders that come from the order URL parameter, not by going back to remembering sort orders that come from clicking column labels.

Comment 8

[Max Kanat-Alexander]

Hm. How would you have preferred (default) sort orders per-user then? Some other way? I suppose we could clutter up the buglist UI with some clickable link to set the sort order as your default. That might be minorly tricky, though--translating the <table> columns back into bugs table column names.

Comment 9

[Bradley Baetz (:bbaetz)]

If you change the sort order on the query page and save it as default, doesn't that do what Jesse wants?

Comment 10

[Max Kanat-Alexander]

(In reply to comment #9)
> If you change the sort order on the query page and save it as default, doesn't
> that do what Jesse wants?

  Yes, but the sort orders listed on the query page are very limited. Also, LpSolit is talking about is that the default sort order is "whatever I used last", so currently, following links can override that without any effective to change it back, if your default sort order is not selectable through query.cgi.

Comment 11

[Jesse Ruderman]

> Yes, but the sort orders listed on the query page are very limited.

Let's fix that instead of continuing with counterintuitive workarounds.

Comment 12

[Max Kanat-Alexander]

That's more of an upstream fix as opposed to something that I'd recommend applying to bmo. 

I think giving Bugzilla the ability to somehow remember the JS sort (if you ask it to) would be better, because that preserves the flexibility without complicating query.cgi even further.

Comment 13

[Bradley Baetz (:bbaetz)]

I thought that the list in query.cgi included your current sort (from the cookie), but it doesn't look like that is the case. That'd be a simple thing, but a separate bug (dependant on this one)

Comment 14

[Dave Miller [:justdave]]

Rearranging this component to not have me as the default assignee, so that it doesn't appear like I'm intending to work on bugs that other people could be taking care of if they didn't think I was already doing them.  If this bug is a software issue on b.m.o and you'd like to fix it, the modified source is now available for the patching (see bug 373688).  Reassigning to the new default owner.

Comment 15

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #4)
> Thats separate (but related); the bug list cookie needs to be updated as well.
> Except thats actually stored in the DB now, isn't it? Fun....

Should I file a separate bug on that? I interpreted this bug title to mean that when I sort by a column header, that sort of the list (referred to by bugzilla as the "last search result") doesn't actually persist for the user.

Due deference to Jesse, but I'd rather take annoying over baffling any day. In the old system, you might sometimes get sort orders you didn't expect, but at least you could fix them by clicking on the appropriate column header. Now you have to go and manually edit the query to get them to persist beyond the search results page.

Comment 16

[Max Kanat-Alexander]

No, I don't think we need a separate--that can be handled here.

Comment 17

[Bradley Baetz (:bbaetz)]

The cookie change is this bug; somehow pushing it back into the db for that other thing (ajax call?) should be separate.

Comment 18

[Max Kanat-Alexander]

(In reply to comment #17)
> The cookie change is this bug; somehow pushing it back into the db for that
> other thing (ajax call?) should be separate.

  The cookie change won't be required--bmo will be using the DB exclusively.

Comment 19

[Dave Miller [:justdave]]

If we don't have any expectationi of resolving bug 425601 in the short term, we should go ahead and have the JS set the cookie for now, to get it working on bmo now.  We can worry about how to get it into the database once we're actually using the database again.

Having the re-sort make an ajax call to update the sort order on the current search sounds like the best plan to me.

Comment 20

[Max Kanat-Alexander]

See also bug 430505.

Comment 26

[David E. Ross]

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 SeaMonkey/2.23

When I logon to bugzilla.mozilla.org and select one of my own custom, stored queries, I want the bug reports ordered by ID Number.  For some reason, the query result orders them by Status.  

The problem is caused by how  Bugzilla sets the LASTORDER cookie.  I cannot get Bugzilla to set the LASTORDER cookie to only "bug_id".  Instead, the cookie is always set to "bug_status%2Cpriority%2Cassigned_to%2Cbug_id".  ("%2C" is a comma.)  If I select the column header "ID" to sort by ID number, logoff from bugzilla.mozilla.org, and log-on again without having terminated SeaMonkey, my queries are again sorted by Status and not ID.  Even if I delete the LASTORDER cookie, it still gets set to "bug_status%2Cpriority%2Cassigned_to%2Cbug_id".  

I can reproduce this problem by launching SeaMonkey in Safe Mode.

Comment 27

[David E. Ross]

As a workaround, I used SQLite on cookies.sqlite to edit the LASTORDER cookie for mozilla.bugzilla.org to have the value "bug_id".  I then marked the file cookies.sdqlite as read-only.  (What an annoyance!)

Comment 28

[Dylan Hardison [:dylan] (he/him)]

Comment #26 seems to represent a different bug. I'm WONTFIXing making the JS order persistent. I'll try to look into making the logic behind LASTORDER make more sense.