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.
email@example.com 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 .)
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
*** Bug 65291 has been marked as a duplicate of this bug. ***
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 firstname.lastname@example.org (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...
moving to real milestones...
correcting version field lost in product move
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
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.
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.
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.
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)
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.
(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)
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).
Max, isn't it something you implemented as part of the b.m.o customization?
Indeed, I did. I wrote the code for 3.0, but it will probably apply to 4.0 pretty easily.
Created attachment 311126 [details] [diff] [review] 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 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.
(See bug 425601, "&last_list in show_bug URLs breaks visited link coloring".)
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.
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.
Created attachment 426195 [details] [diff] [review] Work In Progress Here's a work-in-progress patch for the Referer-based solution.
Created attachment 426222 [details] [diff] [review] 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.
Created attachment 426224 [details] [diff] [review] Actual v2 I attached the wrong patch last time.
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.
(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.
Created attachment 429011 [details] [diff] [review] v3 Thanks for the review, Eric! This version of the patch fixes the problem that Eric found with editing searches.
Comment on attachment 429011 [details] [diff] [review] v3 r=glob
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.
Added to the release notes in bug 604256.