<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=598487) </details> <!--IssueSummary end--> See https://gitlab.com/gitlab-org/gitlab/-/merge_requests/232946#note_3293002799: >>> I looked into this, and it turned out to be a bigger scope than I first thought. The problem is that we attach popovers to a range of elements/components, and the `titleHtml` value might not be readily available for all of them at this time. For example, when linking issues/MRs in the comments using the `!123` syntax, the attributes for the resultant `<a>` element are generated by the backend, which doesn't pass any `data-title-html` attribute to the element, and so it is unavailable to pass on to the `cachedTitle` at the moment. And changing it would be a much bigger scope for this MR. >>> We should attach `data-title-html` to rendered reference links, too. Note that these are only used when the actual work item is unable to be fetched live (or until it's fetched; haven't looked deeper yet). To repro actually seeing the cached value: 1. Load up your GDK. 2. Make a note in a work item and reference another work item (i.e. type `#123` or whatever). 3. Change that target work item's title. 4. Reload the original work item in your browser. 5. `gdk stop rails-web`, or set "No throttling" to "Offline" in Devtools → Network's toolbar: \ {width=258 height=241} 6. Hover over the `#123` work item reference: it'll show the **old** title, not the new one. If you skip step 5, it'll show the new one, as fetched live.