252329 - Returning to buglist after an empty fulltext search causes code error

Status: RESOLVED FIXED

(Bugzilla :: Query/Bug List, defect)

Description

[Jouni Heikniemi]

After a not-so-healthy dose of debugging bonanza, I've come up with the
following reproduction instructions:

1. Wipe your LASTORDER cookie
2. Go to http://landfill.bugzilla.org/bugzilla-tip/query.cgi?format=specific
3. Submit the form with an empty searchword; select FoodReplicator as the
   product*.
4. Click on any bug
5. Click on "show list"
6. Observe Code error "The custom sort order specified in your form submission 
   contains an invalid column name reuse last sort"

*) Product selection is only necessary because without it the buglist will be
too big to fit in a cookie; on an empty test installation you can reproduce this
without filtering.

This was caused by bug 237176, and the process goes like this:

1. A query is considered a full text search iff the content param is set. Thus,
   an ft query with no searchword is not considered an ft query.
2. The order=relevance%20desc is ignored, as the query is not a ft one.
3. Buglist gets filled, but LASTORDER is never set, since we don't really have
   a valid sort order available.
4. When returning to the bug list (regetlastlist=1), the $order is set to 
   "reuse last sort".
5. Later on in the code, it is always assumed that a LASTORDER cookie will 
   exist if "reuse last sort" is set. As it's trivial to tell, this condition
   is breakable in other situations as well.

The correct fix for this is to break the chain above in step 5: if reuse is
specified with an empty cookie, just ignore the reuse directive and skip
sorting. I'll be attaching a patch for this. Although I didn't test this on
2.18rc1 (I don't have a working installation and we couldn't find one on
landfill - Dave?), this bug should be there as well as 237176 was checked in
prior to branching.

Note that this doesn't handle the fundamental and more generic issue of
relevance-sorted buglists not retaining their sort orders after being stored in
a cookie.

Comment 1

[Jouni Heikniemi]

Attachment: v1 for 2.18 branch

Comment 2

[Jouni Heikniemi]

Comment on attachment 153822 [details] [diff] [review]
v1 for 2.18 branch

Myk, can you review this? You're probably the best person to find possible
mistakes in the analysis on comment 0 and the patch...

Comment 3

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 153822 [details] [diff] [review]
v1 for 2.18 branch

This looks good to me, but it doesn't apply to my tip install.

Comment 4

[Joel Peshkin]

Attachment: de-bitrotted version for 2_19

Comment 5

[Christian Reis]

Comment on attachment 153860 [details] [diff] [review]
de-bitrotted version for 2_19

Looks correct. Once order is set to "", it will fall into the default ordering
clause, which is what we should do when we lack the LASTORDER cookie and want
to reuse the "last sort".

Comment 6

[Christian Reis]

Comment on attachment 153822 [details] [diff] [review]
v1 for 2.18 branch

Note: I haven't tested this, just read it thouroughly enough to believe it
fixes Jouni's reported problem. :-)

Comment 7

[Jouni Heikniemi]

attachment 153822 [details] [diff] [review] to branch:

Checking in buglist.cgi;
/cvsroot/mozilla/webtools/bugzilla/buglist.cgi,v  <--  buglist.cgi
new revision: 1.255.2.1; previous revision: 1.255
done

attachment 153860 [details] [diff] [review] to trunk:

Checking in buglist.cgi;
/cvsroot/mozilla/webtools/bugzilla/buglist.cgi,v  <--  buglist.cgi
new revision: 1.258; previous revision: 1.257
done

Comment 8

[Gervase Markham [:gerv]]

*** Bug 252652 has been marked as a duplicate of this bug. ***

Comment 9

[Frédéric Buclin]

*** Bug 263529 has been marked as a duplicate of this bug. ***