When the sort order of a buglist is modified, the "Show next bug in my list" user pref still uses the original sort order to decide which bug to display next

RESOLVED FIXED in Bugzilla 4.0

Status

()

RESOLVED FIXED
8 years ago
6 years ago

People

(Reporter: axiomatic.impact, Assigned: LpSolit)

Tracking

({regression})

Bugzilla 4.0
regression
Dependency tree / graph
Bug Flags:
approval +
approval4.2 +
blocking4.2 +
approval4.0 +
blocking4.0.2 -

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.13 (KHTML, like Gecko) RockMelt/0.9.48.58 Chrome/9.0.597.107 Safari/534.13
Build Identifier: 4.0

In my preferences, I have it the "After changing a bug" setting set to "Show next bug in list".  However, I noticed when changing bugs that it doesn't take the sort into account.  After changing a bug, I would get the bug that was next in the list before the sort.  I can't prove this as of yet, but I'm about 90% sure 3.6 took into account the sorted list.

Reproducible: Always

Steps to Reproduce:
1. Under Preferences, ensure that 'After changing a bug' is set to 'Show next bug in list.
2. Do a search in Bugzilla that results in a list (more than 3) bugs
3. Change the sort of the list by ID number (I always go reverse chronological)
4. Pick a bug, and make any change to it.
Actual Results:  
The result is that it shows the next bug in the pre-sorted list.

Expected Results:  
It should show the next bug in the post-sorted list.

This can be worked around by sorting your list, and then doing another search with the same criteria.  This displays the results with the method of sorting you previously used.  However, if you change the sorting again, it will break again.
(Reporter)

Updated

8 years ago
Version: unspecified → 4.0
Hey Kevin. Unfortunately, due to the nature of the "next bug" system, we'll need more information than this. We have to know the exact series of pages you went through to experience this problem (and what links you used to get from each page to each other page).
(Reporter)

Comment 2

8 years ago
Not a problem, Max.

query.cgi is the Search page I used.  I then did a search that made a list.  On the resulting page, I then sorted by ID.  Doesn't matter how many times you do it, or even what you sort by.  Then I clicked the top bug, which had the resulting URL: show_bug.cgi?id=4327.

The only links and pages I really went to were the Preferences page, Search page, the search results page, and then the bug pages.
Okay, interesting! We'll need somebody on our end to confirm this, and then we can look into it.
Severity: minor → normal
Keywords: qawanted
OS: Windows XP → All
Hardware: x86 → All
confirmed on 4.0.

the buglist "next" and "prev" are also wrong after you change the sort order; they always use the original sort order to derive the next and previous bugs.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Updated

8 years ago
Keywords: qawanted
(Assignee)

Updated

8 years ago
Keywords: regression
Target Milestone: --- → Bugzilla 4.0
(Assignee)

Updated

8 years ago
Duplicate of this bug: 652720
(Assignee)

Comment 6

8 years ago
Marking as blocking 4.0.1 for now, but I will retarget it to 4.0.2 once this flag exists (unless someone can fix this bug before we release 4.0.1).
Flags: blocking4.0.1+
(Assignee)

Updated

8 years ago
Flags: blocking4.2+
Flags: blocking4.0.2+
Flags: blocking4.0.1+

Updated

8 years ago
Assignee: query-and-buglist → mkanat
(Assignee)

Comment 7

8 years ago
...per our current discussion at the IRC meeting...
Assignee: mkanat → LpSolit
Status: NEW → ASSIGNED
(Assignee)

Updated

8 years ago
Depends on: 24896
(Assignee)

Comment 8

8 years ago
Created attachment 543798 [details] [diff] [review]
patch, v1
Attachment #543798 - Flags: review?(mkanat)
Hmm. I'd kind of rather fix this by having Search.pm sort bugs in the order received in bug_id if there's no other specified sort order, but that might not work, eh?
(Assignee)

Comment 10

8 years ago
Well, if we store the sort order in the DB, then we have to update it every time we alter it, else I don't see the point to store it there.
  Oh, I had forgotten we were storing list_order. I wonder if we should stop? Or if it's valuable-enough to users to see the headers set with the proper sort order.

  So, looking over your code, I had a concern that newer searches could overwrite older ones if I used the same list_id in my URL. Is that true?
(Assignee)

Comment 12

8 years ago
(In reply to comment #11)
>   Oh, I had forgotten we were storing list_order. I wonder if we should
> stop? Or if it's valuable-enough to users to see the headers set with the
> proper sort order.

Storing the sort order definitely makes sense. I wouldn't want one query to alter the sort order of other queries (depending on what I'm looking for, the sort order is not the same).


>   So, looking over your code, I had a concern that newer searches could
> overwrite older ones if I used the same list_id in my URL. Is that true?

That's the point, yes. When you update your query, e.g. by altering the sort order, you want to keep the same list ID, because it's the same query.
Okay. I'm concerned about some behavioral aspects of this patch (and possibly logical issues surrounding every possible solution) and so I want to do some more testing and thinking about it.
Flags: blocking4.0.2+ → blocking4.0.2-
(Assignee)

Comment 14

7 years ago
mkanat: could I get review for my patch? This bug is a blocker.
Comment on attachment 543798 [details] [diff] [review]
patch, v1

Review of attachment 543798 [details] [diff] [review]:
-----------------------------------------------------------------

All right, now that I've looked this over, I do actually like most all of it, in general. :-)

::: Bugzilla/User.pm
@@ +501,4 @@
>              }
>  
>              if ($search) {
> +                if (join(',', @{$search->bug_list}) ne join(',', @$bug_ids)) {

Okay, here's my concern. Now, when I go back and forward through my browser history, my search history will be updated in a way that is possibly confusing to me, if my browser re-runs the searches.

  Also, if I update my URL parameters directly (or, say, use an automated tool like BzAPI) I will continuously overwrite the same search.

  How about instead of this, we only update a search that has bugs if the list order has changed but the bug ids are otherwise identical? That doesn't solve the first issue, but it does help with the second issue, at least a bit.

  If there are new bug ids or missing bug ids, then we can create a whole new recent search entry.
Attachment #543798 - Flags: review?(mkanat) → review-
(Assignee)

Updated

7 years ago
Depends on: 703788
(Assignee)

Comment 16

7 years ago
Comment on attachment 543798 [details] [diff] [review]
patch, v1

I still pretend my fix is correct. Only updating the buglist when bugs are added or removed from it doesn't work. This means changing the sort order would be ignored, which we don't want (and is exactly what this bug is about). If the buglist ID is present, update this list if necessary. There is no reason to create another ID for it, else you could fill your history with the same buglist by editing the sort order.
Attachment #543798 - Flags: review- → review?(mkanat)
(Assignee)

Updated

7 years ago
Duplicate of this bug: 704580
(Assignee)

Updated

7 years ago
Attachment #543798 - Flags: review?(glob)
Comment on attachment 543798 [details] [diff] [review]
patch, v1

Review of attachment 543798 [details] [diff] [review]:
-----------------------------------------------------------------

> Okay, here's my concern. Now, when I go back and forward through my browser
> history, my search history will be updated in a way that is possibly confusing
> to me, if my browser re-runs the searches.

i've been unsuccessful in coaxing any browser into re-running the search when navigating back, so i don't think your concern is warranted.

r=glob
Attachment #543798 - Flags: review?(glob) → review+
(Assignee)

Updated

7 years ago
Flags: approval4.2+
Flags: approval4.0+
Flags: approval+
(Assignee)

Updated

7 years ago
Attachment #543798 - Flags: review?(mkanat)
(Assignee)

Comment 19

7 years ago
Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/trunk/
modified buglist.cgi
modified Bugzilla/User.pm
Committed revision 8041.

Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/4.2/
modified buglist.cgi
modified Bugzilla/User.pm
Committed revision 7980.

Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/4.0/
modified buglist.cgi
modified Bugzilla/User.pm
Committed revision 7668.
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Summary: Preference setting "Show next bug in list" for doesn't take into account a sorted list → When the sort order of a buglist is modified, the "Show next bug in my list" user pref still uses the original sort order to decide which bug to display next
I'm still seeing this problem.

For example, if I do the following search:
https://bugzilla.mozilla.org/buglist.cgi?list_id=4147708;emailtype1=exact;email1=dhylands%40mozilla.com;emailassigned_to1=1;query_format=advanced

and then click on the Status field, and click on the first bug in the list (which happens to be bug 744238 when I wrote this) it shows up as 3 of 18, rather than 1 of 18. Clicking Next takes me to 759169 (4 of 18) even though in the sorted list, the Next field would be 694594.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 21

6 years ago
bmo uses a customized JavaScript code to handle column sorting which has nothing to do with the upstream code, see bug 425619. So the problem you are seeing is specific to bmo.
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.