Point issue/PR linkbacks to exact comment that caused the linkback #4553

The issue I see is that probably we just don't know which comment it is. If GitHub points you to the wrong comment, how can we know which comment triggered the notification exactly and which one is actually newest since you last saw the thread?

Example: I mention you in 2 comments, one 3 months ago and one today, but you haven't opened the issue in 4 months. Will RG focus on the latest mention or the 3-month-old mention? We have no idea because we just lack the data to determine which comment triggered the notification and whether you already saw the 3-month-old comment. We can't store a list of every conversation one opens, forever.

Does all of this seem like a technically challenging feature?

Probably, especially because we have 2 options to find out which comment to focus:

• loading the conversation while you're in the Notifications page
• parsing the page or loading more data from the API while you're already on the page

You can image how data-intensive that would be for a Notification page that has the usual 20+ notifications.

And the second one means that by the time we "know" which comment to focus, the browser has already focused the comment chosen by GitHub.

---

My suggestion is to ask GitHub to improve this behavior, perhaps contacting those who work on the notifications page directly, but unless they start pushing multiple notifications like Facebook does, I think that every solution will have compromises.

You have misunderstood the request. This was not about the notifications page at all. This was for the reference events on issues and pull request pages.

I think GitHub already does a good job in focusing the right comment when clicking from the notifications. Come to think of it; even though I did not mention it in the initial description, I was implying similar behavior from the notifications page, on the reference event links.

Ohhh lol my bad. Yeah that much easier to implement because we just need to find the first link on the page after the load. Of course this won't work when the comment/review has been resolved or is hidden, but I suppose it would be good enough.

I suppose we could also use the API to fetch the discussion, but that might get heavy and difficult for review comments.

find the first link on the page after the load.

I am confused.

As I understand it, we need to fetch the event ID which is appended to #issuecomment- which makes the comment focused when navigating to it.

For example, in #issuecomment-877648183, 877648183 is the event ID of the comment. Similarly, we need to find the comment ID for the comments that triggered the reference link and then append the #issuecomment-<eventID> to the URL that would already be pointing to the issue or pull request.

We also need to think about how to handle commit links because commits can also reference issues or pull requests, but they do not need this feature detection.

For all this, I believe we need to be able to fetch the event API stream for each isConversation page specfically on page load and then figure out the event IDs that is required.

I meant find it on the linked issue. In short:

1. User visit issue
2. User sees linkback on current issue
3. Use clicks on linkback, which has no hash
4. Page starts loading
5. Refined GitHub looks for a link to the previous page
6. Refined GitHub changes the hash to that comment, if found

This feature would be split in 2 parts:

• on one load, it finds linkbacks and appends something like #from-sindre/refined-123 which is just a reference to the current page and it doesn’t actually work on its own
• on another load, if the above hash is present, it looks for comments that include a link to sindre/refined/issue|pull/123 and sets location.hash.replace('#issuecomment-1356743') to focus the comment

This requires no API calls.

Does it make more sense now? Am I getting this right?

As for commit links, they’re simply not handled, we could easily exclude them.

We can give this feature a try

wow, that's super smart thinking @fregante! :heart: I was clearly over-thinking in terms of API calls when this could be handled with absolutely no API calls :+1: