24896 - Make First/Last/Prev/Next Work with multiple buglists at once

Status: RESOLVED FIXED

(Bugzilla :: Query/Bug List, enhancement, P2)

Description

[Dan Erikson]

When I am searching through two seperate bug list queries in two different
windows, the First, Last, Prev, Next, and Show list links work off of the
latest query that I preformed.

Steps to reproduce:
Run a query in bugzilla.
Open a bug from that query list.
Open a new window.
Run a different query in that window.
Go back to the first window and click on the Show list link.

Result:
The list shown is from the second query.

Expected Result:
Should show the list from the first query.

Comment 1

[Terry Weissman]

Yeah, I know.  This is because it uses cookies, and cookies are browser-wide. 
There's no way to limit a cookie to a window.

Bugzilla (and it's predecessor, BugSplat) has always had this problem.

The only way I know to fix this would be to pass around some token as a form
element or URL parameter to every page you visit.  Which is a fine technique,
but a real coding grind.

If anyone has some other suggestions, I'd love to hear them.

Comment 2

[Terry Weissman]

[e-mail] is the new owner of Bugzilla and Bonsai.  (For details,
see my posting in netscape.public.mozilla.webtools,
news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)

Comment 3

[Gervase Markham [:gerv]]

This bug has not been touched for more than nine months. In most cases, that 
means it has "slipped through the net". Please could the owner take a moment to 
add a comment to the bug with current status, and/or close it.

Thank you :-)

Gerv

Comment 4

[Jacob Steenhagen]

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

Comment 5

[Dave Miller [:justdave]]

Since bug 65291 got marked as a dupe of this one, and it had a lot of good 
discussion in it, here's the relevant discussion from 65291:

Original text from [e-mail] (Keyser Sosez):

Please please please, for the sake of the sanity of the bug triagers code 
Bugzilla so it doesnt clobber the results from the first search you do.  For 
example:

1) Run any bugzilla query
2) On the list that comes up click on any bug to get its details
3) Open a New Window
4) Run another bugzilla query
5) Go back to first window and click on any of the links such as: Next, Prev,
First, Last
6) Watch as bugzilla goes to the first result of the other query.

This may not seem like a big deal but when your looking for duplicates of an 
unconfirmed bug, everytime you want to go to the next bug you have resubmit the 
query, thus losing your place. Its a waste of time, and drives the bug triagers 
insane. Please please fix :)

------- Additional Comments From Dave Miller 2001-01-12 18:28 -------

This was discussed in IRC this evening.  Possible solution:

Assign each query a number.  Create a new cookie with each query, with that  
number in the cookie name.  Each time a user does a query, use whatever the next  
unused number is.  That number can then be placed in the "Prev", "Next", "Show  
List", etc. links so it knows which one to use when the link is clicked in that  
particular window.

Pick a reasonable number of queries (10?) and start deleting cookies when you get 
more than that many of them, to prevent cookie bloat.

------- Additional Comments From Jesse Ruderman 2001-01-12 20:33 -------

Can this be done without destroying the "visited" state of buglinks on query  
result pages?

------- Additional Comments From Dave Miller 2001-01-12 20:42 -------

Ooohhh...  yeah, you'd need to have some way in the bug link to tell the newly- 
viewed bug which buglist it was linked to from.  Hadn't thought about that.   
Ouch.

------- Additional Comments From Dave Miller 2001-01-12 20:50 -------

Hmm, thought on that subject....
The cookies actually store a list of bug numbers (in the current implementation 
already in use).  If it continues to do that, all it would need to do is look to 
see which cookie it's mentioned in, then use that one.  If it was a hit in more 
than one query, perhaps supply more than one set of Next/Prev/First/Last/Show 
links, with the query numbers in front of each line...

Comment 6

[Dave Miller [:justdave]]

moving to real milestones...

Comment 7

[Zach Lipton [:zach]]

moving

Comment 8

[Dave Miller [:justdave]]

correcting version field lost in product move

Comment 9

[Gervase Markham [:gerv]]

Another way to fix this bug is based on the way people actually use buglists.

You often have one big buglist you are working through, and make loads of other
little queries, e.g. to try and find dupes. You normally don't iterate through
those queries, but scan them by looking down the list.

So, the solution is to have a checkbox on query.cgi which stops Bugzilla from
updating the cookie. Something like "Do not generate navigational links for this
query" or something. You'd check that when you did the little queries.

Or, you could have two submit buttons. This might be quicker.

Gerv

Comment 10

[Dave Miller [:justdave]]

We are currently trying to wrap up Bugzilla 2.16.  We are now close enough to
release time that anything that wasn't already ranked at P1 isn't going to make
the cut.  Thus this is being retargetted at 2.18.  If you strongly disagree with
this retargetting, please comment, however, be aware that we only have about 2
weeks left to review and test anything at this point, and we intend to devote
this time to the remaining bugs that were designated as release blockers.

Comment 11

[John Vandenberg]

Gerv's suggestion is a very simple solution which will save users a lot of time,
and reduce the number of times queries are run.  I have raised bug 138351 to
propose it as an interim solution.

Comment 12

[José Henrique F. Melman]

A possible solution: when searching, the generated page's links should contain
the timestamp of the search. The cookie BUGLIST should be renamed to something
like  BUGLIST20030731123405. When clicking on a link in the generated page, the
server would receive the timestamp of the search and read the appropriate cookie.

I don't know much about cookies, I don't know if it is possible to have numbers
in the cookie name, but a "translation" should not be difficult: just get the
NTP timestamp in hex form and then make 0 become A, 1 become B, ... , F become P.

Comment 13

[Dave Miller [:justdave]]

Enhancements which don't currently have patches on them which are targetted at
2.18 are being retargetted to 2.20 because we're about to freeze for 2.18. 
Consideration will be taken for moving items back to 2.18 on a case-by-case
basis (but is unlikely for enhancements)

Comment 14

[Dave Miller [:justdave]]

Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.

Comment 15

[Wayne Mery (:wsmwk)]

(In reply to comment #12)
> A possible solution: when searching, the generated page's links should contain
> the timestamp of the search. The cookie BUGLIST should be renamed to something
> like  BUGLIST20030731123405. When clicking on a link in the generated page, the
> server would receive the timestamp of the search and read the appropriate cookie.

my preference of the options presented. I am not against a check box ala gerv's
comment 9 (bug 138351) but the suggestion above would be more helpful. (hmm,
according to comment 8 patch in Bug 138351 is bitrotted)

Cookie expiration becomes the next issue.

(surprised nothing has been implemented, as it seems easy to address and is
definitely benificial to triagers - mulitiple query lists are a frequent occurrenc)

Comment 16

[Frédéric Buclin]

The trunk is now frozen to prepare Bugzilla 2.22. Only bug fixes are accepted, no enhancement bugs. As this bug has a pretty low activity (especially from the assignee), it's retargetted to ---. If you want to work on it and you think you can have it fixed for 2.24, please retarget it accordingly (to 2.24).

Comment 17

[Frédéric Buclin]

Max, isn't it something you implemented as part of the b.m.o customization?

Comment 18

[Max Kanat-Alexander]

Indeed, I did. I wrote the code for 3.0, but it will probably apply to 4.0 pretty easily.

Comment 19

[Max Kanat-Alexander]

Attachment: v1 (3.0)

I haven't actually tried to apply this to the trunk, but you could still look it over and let me know what you think about the design, and so on. I think maybe we should have an object for the last searches instead of just a hash.

Comment 20

[Frédéric Buclin]

Comment on attachment 311126 [details] [diff] [review]
v1 (3.0)

The implementation on b.m.o made some users unhappy, because history was broken due to the appended arguments to URLs. I think that's a valid point as I also look at links to determine if a bug has already been visited or not. That's not something we should break.

Comment 21

[Jesse Ruderman]

(See bug 425601, "&last_list in show_bug URLs breaks visited link coloring".)

Comment 22

[Max Kanat-Alexander]

We can fix this by:

1. Including a search_id argument in the buglist.cgi URL somehow.
2. When you click on a bug, it checks its Referer to see if it's coming from
   buglist.cgi, and pulls the correct list out of the Referer.
3. Once the bug is loaded, the First/Prev/Next/Last buttons just use the
   search_id directly and don't need to check the Referer.

The tricky part is #1.

Comment 23

[Max Kanat-Alexander]

We can possibly accomplish #1 by doing it during the POST conversion step of buglist.cgi (that is, where it shortens the search URL), since we have the whole search there anyhow.

Comment 24

[Max Kanat-Alexander]

Attachment: Work In Progress

Here's a work-in-progress patch for the Referer-based solution.

Comment 25

[Max Kanat-Alexander]

Attachment: v2

Okay, here it is.

The bug lists of searches are saved to the database after they are run. They are given an id, and this id appears in the URL after the search is redirected from the initial POST from query.cgi.

When viewing a bug, it attempts various ways to figure out what list the bug is associated with. When you've actually used the First/Prev/Next/Last buttons, it's a no-brainer, because they include the list_id in their links. But to preserve visited-link coloring in the bug lists, we don't include list_id in the links there--instead, when viewing a bug, we check the Referer header for a list_id.

If you view a bug without having come from a bug list, and if there's no list_id in query parameters, then we simply look for the most-recent search that contains this particular bug, and we decide that that's the list. (This is how things will work for Saved Searches currently, since they have no list_id in their header, since they go from a GET.)

It still uses the BUGLIST cookie for logged-out users.

Comment 26

[Max Kanat-Alexander]

Attachment: Actual v2

I attached the wrong patch last time.

Comment 27

[Eric Black]

I started with a functional test and I came across the following bug:

1. Run a search from the query.cgi page

2. Go into one of the bugs in the list

3. Click on the 'show last search results', which has a URL like:
http://192.168.2.176/bugzilla/buglist.cgi?regetlastlist=8

4. It goes back to the original list ok.

5. Click on 'edit search', which has a URL like(doesn't seem right to me):
http://192.168.2.176/bugzilla/query.cgi?bug_id=1&bug_id=2&bug_id=3&query_format=advanced

6. The query.cgi page displays with no original parameters selected and only has the first bug number from #5 url (bug 1) in the 'Only include bugs numbered:' edit box.



I reverted the changes and the url for 'edit search' was http://192.168.2.176/bugzilla/query.cgi?bug_id=1%2C2%2C3&query_format=advanced and had bug 1,2,3 in 
the 'Only include bugs numbered:' edit box. (That in itself seems like a bug since it isn't returning my original search parameters like the original buglist 'edit search' URL which was http://192.168.2.176/bugzilla/query.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&query_format=advanced).



BTW, shouldn't bug 138351 be marked as depending on this bug or linked to it so if this bug fixes the problem, bug 138351 can be marked obsolete.

Comment 28

[Eric Black]

(In reply to comment #27)

> I reverted the changes and the url for 'edit search' was
> http://192.168.2.176/bugzilla/query.cgi?bug_id=1%2C2%2C3&query_format=advanced
> and had bug 1,2,3 in 
> the 'Only include bugs numbered:' edit box. (That in itself seems like a bug
> since it isn't returning my original search parameters like the original
> buglist 'edit search' URL which was
> http://192.168.2.176/bugzilla/query.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&query_format=advanced).
> 

I created Bug 546821 for the problem that isn't from this patch, so only item 6 in comment #27 is from the patch.

Comment 29

[Max Kanat-Alexander]

Attachment: v3

Thanks for the review, Eric! This version of the patch fixes the problem that Eric found with editing searches.

Comment 31

[:glob ✱]

Comment on attachment 429011 [details] [diff] [review]
v3

r=glob

Comment 32

[Max Kanat-Alexander]

Woohooo!! :-)

Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/trunk/
modified buglist.cgi
modified Bugzilla/CGI.pm
modified Bugzilla/Constants.pm
modified Bugzilla/Template.pm
modified Bugzilla/User.pm
modified Bugzilla/Util.pm
modified Bugzilla/DB/Schema.pm
added Bugzilla/Search/Recent.pm
modified template/en/default/bug/navigate.html.tmpl
modified template/en/default/global/user-error.html.tmpl                       
Committed revision 7210.

Comment 33

[Max Kanat-Alexander]

Added to the release notes in bug 604256.