LASTORDER cookie breaks after multiple resorts

RESOLVED DUPLICATE of bug 510944

Status

()

Bugzilla
Query/Bug List
P2
normal
RESOLVED DUPLICATE of bug 510944
13 years ago
9 years ago

People

(Reporter: John Neilson, Unassigned)

Tracking

Details

(Reporter)

Description

13 years ago
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.

Comment 1

13 years ago
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

Comment 2

13 years ago
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.
(Reporter)

Comment 3

13 years ago
Thanks, I'll give that a look!

Comment 4

13 years ago
That patch will help when you use a small number of sorts over and over.

This still breaks if you use enough distinct sorts.
(Reporter)

Comment 5

13 years ago
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?

Comment 6

13 years ago
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

Updated

11 years ago
Target Milestone: Bugzilla 2.22 → Bugzilla 3.0

Comment 7

10 years ago
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.

Comment 8

10 years ago
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

Comment 9

9 years ago
I'm pretty sure it's the same root cause as bug 510944.
Status: NEW → RESOLVED
Last Resolved: 9 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.