User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 I have a user that has come across this one a couple of times now. Resorting the search results by clicking on the column headers prepends the main sort field to the list in the LASTORDER cookie, but after numerous resorts the cookie hits the 256 char point and truncates. The next time the sort fields from the cookie are used to sort the results, there's a SQL error because the last (truncated) fieldname in the list is now invalid. Reproducible: Sometimes Steps to Reproduce: 1. Search and get a results list 2. click on a column head to resort 3. check length and contents of LASTORDER cookie in browser 4. repeat as necessary, reusing sort columns as desired to see duping Actual Results: Once the 256 char limit is reached, last field is truncated. Expected Results: Ideally the list should be cropped cleanly after the last fieldname that can fit within the 256 chars. Since some users will sort first one way and then another as they analyze search results, I'm seeing sort fields entered into their LASTORDER cookie multiple times. De-duping the field list in the cookie would go a long way towards lessening the problem. If all the fieldnames fit with in 256 chars, this might even constitute a partial "fix". A hacky workaround would be to occasionally clear the LASTORDER cookie, or give the user a button to clear it on demand, since that's what I end up having to do to get the user up and running again anyway. This is in 2.16.7 I did a few searches and didn't see any open or closed bugs for this. Apologies if this has been fixed in a later version or I just missed it.
Yeah, this happens in the tip. To do this, change columns so that everything is displayed and then sort by each column in turn.
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Priority: -- → P2
Hardware: PC → All
Target Milestone: --- → Bugzilla 2.20
The list should be de-duped on the trunk, thanks to a patch I wrote for bug 179451 that moves ORDER BY generation into Search.pm. You may be able to apply that patch to your local installation, if you'd like. It should help.
Thanks, I'll give that a look!
That patch will help when you use a small number of sorts over and over. This still breaks if you use enough distinct sorts.
This user was constantly resorting by clicking on column heads, so I would interpret that as a relatively small number of fixed sorts. I looked at that final patch in bug 179451, but haven't gone through it line-by-line yet. Can I assume that it's sufficient and self-contained, no hidden dependencies for a 2.16.7 installation?
I don't think that this is critical or necessary to fix for 2.20, now that we've somewhat mitigated the problem by unique-ifying the sort order.
Severity: major → normal
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
Version: unspecified → 2.18
I think something in the recent upgrade here on b.m.o made this bug a lot more visible, because I had never hit it until last week, and now even clearing the cookie doesn't seem to restore a sane search order. The workaround was to clear the cookie and perform a search, specifying the sort order I wanted at the bottom of the search form. That seemed to get it working again, although if I had wanted anything besides the options in that popup (sort by bug number, importance, assignee, last-changed), I'm not sure how I'd go about fixing it.
The Bugzilla 3.0 branch is now locked to security bugs and dataloss fixes only. This bug doesn't fit into one of these two categories and is retargetted to 3.2 as part of a mass-change. To catch bugmails related to this mass-change, use lts081207 in your email client filter.
Target Milestone: Bugzilla 3.0 → Bugzilla 3.2
I'm pretty sure it's the same root cause as bug 510944.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Target Milestone: Bugzilla 3.2 → ---
Duplicate of bug: 510944
You need to log in before you can comment on or make changes to this bug.