425601 - &last_list in show_bug URLs breaks visited link coloring

Status: RESOLVED FIXED

(bugzilla.mozilla.org :: General, defect)

Description

[Jesse Ruderman]

All bug links in searches now have "&last_list=###" appended to their URLs.  The ### is different for each search.

I rely on being able to tell which bugs I've visited, and I paste bug links into IRC and other web pages many times per day, so this breaks Bugzilla quite a bit for me.

I think this bug appeared with the upgrade to Bugzilla 3.0.3 earlier today.

Comment 1

[Reed Loden [:reed]]

Yeah, this is a bad usability regression, considering it breaks history.

Comment 2

[Dave Miller [:justdave]]

The last list thing is a power-user feature.  Maybe have the href= be the plain
link and have an onclick that appends the list id just before it fires off the
link?  That way it wouldn't show up with a right-click/copy link location also,
right?

Comment 3

[timeless]

fwiw, the edit users search page does this nonsense too. bonus points for getting them to fix that at the same time.

Comment 4

[Jesse Ruderman]

> The last list thing is a power-user feature.

I'm a power user and I have never used the bug-list-traversing features.

> Maybe have the href= be the plain link and have an onclick
> that appends the list id just before it fires off the link?

That would still break copying from the address bar (or even from the bug list) after clicking a bug link.

This new "feature" should be opt-in per list with a "I want to traverse this bug list while being able to make other searches" button at the bottom of the list, IMO.

Comment 5

[Reed Loden [:reed]]

(In reply to comment #4)
> > The last list thing is a power-user feature.
> 
> I'm a power user and I have never used the bug-list-traversing features.

I agree. I've always found it easier just to open new tabs for each bug instead of using the first/next/etc. stuff.

Comment 6

[timeless]

this isn't a power user feature, it's a "manager user feature". they should be opt in, possibly "i'm a manager simply me".

I'm perfectly fine w/ this last_list feature and the editusers equivalent ONLY IF they default to off and have an opt in. I'm also fine w/ them sharing an opt in.

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #5)
> I agree. I've always found it easier just to open new tabs for each bug instead
> of using the first/next/etc. stuff.

That way, you get the network load while you're acting on the first bug, and can move on to the next ones without waiting on it to load :)

Comment 8

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #0)
> I rely on being able to tell which bugs I've visited, and I paste bug links
> into IRC and other web pages many times per day, so this breaks Bugzilla quite
> a bit for me.

Agree completely. I rely on being able to filter out visited buglinks a lot.

Comment 9

[timeless]

<Jesse> proxyvictim: if it's going to be a pref, i wouldn't tie it to that pref, although setting the new pref for existing users based on the existing pref might be reasonable

can't we have a cookie which says "bugX-listY"?

1. When you load a bug it checks referer.
 A. if referer is a buglist, it stores bugX-listY
 B. if referer was a bug W and says W was in listY then it sees if X is in listY and if so updates your cookie to that and uses the proper buglist

the editusers stuff is trivially fixed by using referer. and any manager privacy conscious enough to break same site referer deserves to lose :)

Comment 10

[Dave Miller [:justdave]]

22:18:08 <@justin> justdave: think we should pull that till we get a better implementation


modified Bugzilla.pm
modified buglist.cgi
modified show_bug.cgi
modified Bugzilla/Constants.pm
modified Bugzilla/User.pm
modified Bugzilla/DB/Schema.pm
modified template/en/default/bug/navigate.html.tmpl
modified template/en/default/global/user-error.html.tmpl
modified template/en/default/list/table.html.tmpl
Committed revision 5180.
------------------------------------------------------------
revno: 5180
committer: David Miller <[e-mail]>
branch nick: bugzilla-test
timestamp: Thu 2008-03-27 15:21:35 -0700
message:
  Backing out revision 5161 (remember last 10 buglists for bug navigation) pending resolution of bug 425601

[root@mradm02 bugzilla.mozilla.org]# bzr up
 M  Bugzilla.pm
 M  Bugzilla/Constants.pm
 M  Bugzilla/DB/Schema.pm
 M  Bugzilla/User.pm
 M  buglist.cgi
 M  show_bug.cgi
 M  template/en/default/bug/navigate.html.tmpl
 M  template/en/default/global/user-error.html.tmpl
 M  template/en/default/list/table.html.tmpl
All changes applied successfully.
Updated to revision 5180.


Should be live in production in about 15 minutes.

Comment 11

[Max Kanat-Alexander]

The originally requested requirement was to know exactly what bug list your bug came from and thus be able to navigate through that exact bug list.

There are only four ways of passing state between pages: GET variables, POST variables, HTTP request headers (such as Referer), and Cookies (a special case of headers).

Any solution to the original enhancement request has to handle an enormous complexity of simultaneously open windows or tabs in one user's browser--a not uncommon occurrence. The solution has to work from a buglist you opened X lists ago in some tab, and also from show_bug.cgi for any bug opened from any list you've had open recently.

As you can imagine, Cookies are thus not a solution. They're handy for tracking general state for a domain, but not so much for the kind of complex state that we need here. They're also the solution that we're trying to get away from, because of the length limit (that's where the old "Bugzilla's little mind" message comes from).

GET variables are what the current solution uses.

We could convert the links to POST (via JS) the additional variable, but nobody wants to POST every time a bug is opened.

That leaves the Referer header. Unfortunately that doesn't help us on show_bug.cgi (remember the case where one bug is in three different lists). Also, it doesn't help us much coming from buglist.cgi since the buglist.cgi URL is a huge complex mess with no unique identifier. It's too long to store in the database and match on with an index.


As I'm sure you know, you can still share links with the last_list in them. It doesn't affect anybody else's ability to view the bug.

I do understand the history concern.


I suppose the thing to ask here is why was this requirement desired? Who wanted it? How would *those people* like it to behave? Are they people who would be aware of a preference and actually find it important enough to turn it on, or would they just complain that Bugzilla sucks and have to be told about the preference (if somebody happened to be on hand to tell them)?

If there are no consumers of this feature, then it would probably be simpler to just not have it. If there are consumers, I suppose we should ask them what they want.


Note that if you're willing to sacrifice the "this bug is in multiple bug lists" case to just reduce to "always use the last list this bug was in" (which I think would confuse managers), then we can eliminate the state-passing altogether.

Comment 12

[Justin Fitzhugh]

I think the functionality you provided is actually perfect - just keep that functionality, but without breaking history and we'll have a good solution.  Possible?

Comment 13

[Dave Miller [:justdave]]

I wasn't too concerned about the history, personally.  I liked it the way it was implemented.  Maybe having a preference (default on? the people who want their history seem to be a vocal minority, and also tend to be the people who would find a preference) would be good.

Comment 14

[Jesse Ruderman]

I think the people who navigate through bug lists are a tiny minority (mostly managers), and people who share bug links and care about history are not a minority at all.

Comment 15

[Max Kanat-Alexander]

(In reply to comment #12)
> I think the functionality you provided is actually perfect - just keep that
> functionality, but without breaking history and we'll have a good solution. 
> Possible?

  Only in the case of the last paragraph of comment 11.

Comment 16

[Max Kanat-Alexander]

Also, people might be more likely to start using the bug list navigation now that new searches won't overwrite it, so it might not be good to judge the use of the feature based on how many people use it now.

Comment 17

[Dave Miller [:justdave]]

Rearranging this component to not have me as the default assignee, so that it
doesn't appear like I'm intending to work on bugs that other people could be
taking care of if they didn't think I was already doing them.  If this bug is a
software issue on b.m.o and you'd like to fix it, the modified source is now
available for the patching (see bug 373688).  Reassigning to the new default
owner.

Comment 18

[Dave Miller [:justdave]]

well, the obvious thing to do is to leave the default to be to work they way it does now, and advertise to people that it's available if you go in your preferences and turn it on, and see how many people go turn it on.

Comment 19

[Gervase Markham [:gerv]]

This got backed out, so the bug as written is FIXED. And Bugzilla 4.0 has a new mechanism for this which (I am told) doesn't involve URL parameters.

Gerv