browsing to bug comment permalink should show comment in context

Hello Amir,

thanks for the report.
I'm afraid I don't understand this bug report. You mean we should add to each individual comment page a link back to the comment anchor, is that correct?

Cheers.

No.

I suggest to add <a name="comment42"> (replace 4 with comment number) before every comment on the main bug page.

Currently every comment has something like this:
===========================================
      <a href="https://bugs.launchpad.net/~matsubara"><img alt="" width="14" height="14" src="/@@/person" />&nbsp;Diogo Matsubara</a>
===========================================

I suggest to change it into something like this:

===========================================
      <a name="comment1" href="https://bugs.launchpad.net/~matsubara"><img alt="" width="14" height="14" src="/@@/person" />&nbsp;Diogo Matsubara</a>
===========================================

This way i can send someone a link such as https://bugs.launchpad.net/malone/+bug/124166#comment1 and he will see comment 1 and the comments after it. This may be useful for pointing someone into a middle of a long discussion where there is need to see the comment and the replies to it.

I second this.
Another option (instead of <a name="commentX"> would be an ID for the HTML element starting the comment, e.g.
<div class="boardCommentDetails" id="commentX">
(where X is the comment's number).

I really like this idea!

Things we should consider:

* What are the implications for performance (rendering all the comments for a bug with many comments can be expensive)
* What are the usability implications? Is there still a use for a single comment view?
* What can we do for bug pages where we trim the comments? (maybe turn them on automagically with a script)?

Thanks, Tom!

* Note that rendering all the comments is something we do anyway if the user visits the bug itself, rather than a particular comment. So it's not like the cost is worse here...

* I frankly don't think there is ever a use for single-comment-view. When would a user want to see just the comment and not have immediate (via scanning/scrolling) access to the context around it? Never, or at least so vanishingly rarely as to not be worth supporting.

* The question of trimming comments or having contination pages ("first 50; next 50; etc") is really independent of this issue. It's a general bug tracker interface decision; if we were to implement it, then we'd use it both when visiting the whole bug, and when jumping to a particular comment in the middle of a bug.

(Or do we currently implement continuation pages? I don't think I've ever visited a bug long enough to see that happen...)

Of course, we'd ideally always place the target comment in the middle of the shown set of comments. IOW, if someone jumps to "#comment-51", we still want to show that comment in the middle of its context, comments 25 through 75, rather than showing 51 at the top of the screen and going down to 100.

2009/2/7 Karl Fogel <email address hidden>:

> * I frankly don't think there is ever a use for single-comment-view.
> When would a user want to see just the comment and not have immediate
> (via scanning/scrolling) access to the context around it? Never, or at
> least so vanishingly rarely as to not be worth supporting.

Note that we can support that and still implement the change proposed
here. What I'm asking is whether we want to stop supporting it.

> * The question of trimming comments or having contination pages ("first
> 50; next 50; etc") is really independent of this issue. It's a general
> bug tracker interface decision; if we were to implement it, then we'd
> use it both when visiting the whole bug, and when jumping to a
> particular comment in the middle of a bug.
>
> (Or do we currently implement continuation pages? I don't think I've
> ever visited a bug long enough to see that happen...)

We are just about to introduce the trimming of comments on the initial
bug page if they go beyond 100.

> Of course, we'd ideally always place the target comment in the middle of
> the shown set of comments. IOW, if someone jumps to "#comment-51", we
> still want to show that comment in the middle of its context, comments
> 25 through 75, rather than showing 51 at the top of the screen and going
> down to 100.

I don't think we'll ever do paging, but instead progressively load
comments, so that you can view them all on the same page, but you
don't have to load them at the same time. If so, then we'll need some
way for the page to know that it must load the relevant comment.

Yeah, I'd say let's just stop supporting the single-comment view.

Re progressive loading: sounds like the API should be something like: load this bug, making the requested comment visible with surrounding context. (Then standard bug page load calls that with comment-1 as the argument.) When the comment is off in the middle somewhere, then some sort of vertical visual ellipsis elides the comments outside the context range until they're loaded.

> Yeah, I'd say let's just stop supporting the single-comment view.

People have bookmarks to comments etc (displayed in the interface as "permalinks", no less) so you have to have some sort of transition plan if you wish to abandon the single-comment view.

There are bugs with a large number of comments where e.g. a workaround is hard to spot even if you have a link to that comment within a page. It might be more usable in those cases to be able to link to just the isolated comment.

These are marginal cases as such, but I fathom it's not altogether a large burden to keep the single-comment view around, and with these complications, perhaps it would be simpler to keep it as an option.

Compatibility certainly implies continued support for the old URLs (they should forward to the new ones). But seeing which comment is being pointed to, even in context, is easy with the right visual cues. To give you an idea of what it looks like, here's a web page that uses the technique:

   http://producingoss.com/#podcasts

Similarly, if the targeted comment were clearly bordered in red (or whatever), there would be no doubt about where the reader's attention should go first.

2009/2/8 Karl Fogel <email address hidden>:
> Compatibility certainly implies continued support for the old URLs (they
> should forward to the new ones).

I think that this is a good solution.

I agree that the single-comment view should be retired, but one thing that hasn't been mentioned yet is that the single-comment view is the current method of showing the full version of a comment that is truncated on the bug report page. That would need to be solved another way (see also bug 78911).

I was about to file a bug "put IDs in bug comments so people can link to them in context" and found this.

While you figure out what to do about standalone comments and existing comment links, could you at least add some kind of ID or name attribute to the comment template (as comment #2 suggests) so that people can manually fabricate a bug URLs with a fragment linking to a comment? You're already sticking #NNN in td class="bug-comment-index", just add id="NNN" to that. Currently the HTML of the entire comment section of a bug is devoid of name/id attributes. If the Launchpad code is browseable online I could guess at a patch.

This would also allow the nifty enhancement of hyperlinking of references in comment text such as "Regarding comment 2" and "See bug 518172 comment 12"; Bugzilla automatically hyperlinks those.

It looks like changing line 48 in https://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/annotate/9232.2.70/lib/lp/bugs/templates/bugcomment-box.pt

- <td class="bug-comment-index">
+ <td class="bug-comment-index" tal:attributes="id string:${comment/index}">

would put an id attribute on the bug comment, though my bazaar/TAL/Zope-fu is nonexistent. HTH.

It should also be good to apply the patch to the Answers parts of Launchpad