Extend issue context popup beyond markdown content

[silverwind]

Extend the issue context popup beyond markdown. Any link rendered with the ref-issue class now gets the popup, which covers commit titles and issue titles everywhere they appear (repo home, commits list, blame, branches, graph, PR commits, issue/PR pages, compare, …). For surfaces that synthesize links without markdown autolinking (dashboard activity feed, pulse page, commit merged-PR line), opt in by adding data-ref-issue-container on a parent (or ref-issue on the link).

• Use html_url from the backend payload instead of synthesizing links client-side
• Fetch outside the component, stateless, with a per-URL cache
• Small hover delay so passing over a link doesn't fire a request
• Drop the loading state (shifted layout)
• Make both links in the tooltip work; prevent nested tooltips
• Fix feed title <a> width so the tooltip only shows on link hover

---

This PR was written with the help of Claude Opus 4.7

[bircni]

Just an Idea but what about also showing the actions state? so X or whatever to see PRs state

[wxiaoguang]

Is it really right to show the popup everywhere?

Is it your decision or your AI's decision?

[silverwind]

Right, on issue list it probably make no sense, project is debatable. Will investigate how GitHub does this.

[wxiaoguang]

Please make sure the framework is designed by the correct approach:

let callers tell framework what they want, but not let framework guess what it should do for different callers.

You need to explicitly declare "the links need to show issue ref popup", but not make the popup logic try to guess and exclude.

[silverwind]

You need to explicitly declare "the links need to show issue ref popup", but not make the popup logic try to guess and exclude.

I'd rather have an opt-out than an opt-in. Less work overall because the majority of issue links benefit from the tooltip.

[wxiaoguang]

You need to explicitly declare "the links need to show issue ref popup", but not make the popup logic try to guess and exclude.

I'd rather have an opt-out than an opt-in. Less work overall because the majority of issue links benefit from the tooltip.

Maybe you forgot how many bugs were caused by various global pollutions. You will introduce more global pollutions and more bugs.

[silverwind]

bc1cd33 adds the skip for all places where information is duplicate, consistent with GitHub.

[wxiaoguang]

I think I have been clear: if you design a global framework or approach, you should make it have clear behavior, but not guess.

Such code can not be right:

    if (link.closest('.ref-issue-popup, #issue-list, #project-board, .milestone-issue-list')) return;

You should explicitly add the class "ref-issue" to the links you need to popup, or add something like "ref-issue-container" to the container of the links, but not let the framework function know everything or keep guessing.

---

By the way, manually constructing links is very fragile, backend should already tell you the "repo link" or "issue link"

[silverwind]

A opt-out is clearly better than opt-in for this. There are exactly 3 cases where popup does not make sense compared to 100+ where it does.

[silverwind]

I may have misread, I'll do the opt-out via attribute and check if links are already available somewhere.

[silverwind]

1. Opt-out via data-no-ref-issue-popup attribute on any parent
2. Re-use html_url

Opt-in is a no-go for me, there are 3 self-referencing locations that don't need it vs. probably 50+ locations that do need it.

[silverwind]

Did opt-in fb651ea, the number of locations that needed it was actually much smaller than expected.