Lets chat about this tomorrow! This is specifically being caused due to the installation of Wikibase on a Wiki.

Since we aren't going to initially deploying to a wiki that has Wikibase, it's not a problem we necessarily would need to solve initially.

Agreed that it may not be needed for the current milestone after Seddon comment, but I wanted to share that after a discussion with Matthias we thought to use the QID if possible as the new data attribute. Doing so would actually save the UI from having to do an extra API call (currently we need to do an API call do fetch the QID and then do another for commons and wikidata info).

@SimoneThisDot @Seddon Is using the QID part of this ticket, part of another ticket, or do we need a new ticket for it? I'd like to move this one to the backlog if it's not needed for the first few milestones.

Simone's last comment is already part of this ticket; just a more specific potential implementation of whatever fix we'll come up with here.

We're going to need to do this right now.
Not only are we going to need a more efficient way to fetch the Qid (we're wasting a lot of resources doing a redundant API call, and it's also slowing down how fast the quickview is able to open), but even more importantly: recent development revealed that current way is also not without issues and simply doesn't work for some results.

Note: my last comment was wrong.

• we're not wasting resources doing a redundant API call - we already have the Qid available from one of the existing calls
  • it's still going to slow down Commons/interwiki results because we can't start doing those requests until we have the ID, but that may not be a big deal and doesn't need to be addressed right away
  • in fact, fetching all Qids ahead of time will also have a (likely minor) impact, so it may even be undesirable
  • if we do want/need to resolve the Qid ahead of time, doing so within wgSpecialSearchTextMatches (in our extension) probably makes more sense then in a data attribute (in core)?
• we do still need to fix the title thing (I'd suggest to add another data attribute with the actual page title, e.g. data-title="..."), which is a pretty small and important fix, but indeed also not immediately required because of the wikis we roll out to.

TL;DR:

• this ticket is exclusively about exposing the correct page title; it's an important fix, but can probably be moved to a later milestone (though I'd recommend dealing with it as early as possible - there may be more special cases beyond all of Wikidata; e.g. I wonder if this feature could also conflict: https://en.wikipedia.org/wiki/Wikipedia:Page_name#Changing_the_displayed_title)
• additional optimizations (like resolving Qid ahead of time) are under consideration; new ticket will be filed to address those, if needed

In T317639#8267608, @matthiasmullie wrote:

TL;DR:

• this ticket is exclusively about exposing the correct page title; it's an important fix, but can probably be moved to a later milestone (though I'd recommend dealing with it as early as possible - there may be more special cases beyond all of Wikidata; e.g. I wonder if this feature could also conflict: https://en.wikipedia.org/wiki/Wikipedia:Page_name#Changing_the_displayed_title)
• additional optimizations (like resolving Qid ahead of time) are under consideration; new ticket will be filed to address those, if needed

Thanks @matthiasmullie! I'm moving this to Milestone 4 based on your comment -- please let me know if anything changes.

Change 894226 had a related patch set uploaded (by Simone Cuomo; author: Simone Cuomo):

[mediawiki/extensions/SearchVue@master] Enhance the way the QuickView links searchResult to QuickView article

https://gerrit.wikimedia.org/r/894226

Change 894226 merged by jenkins-bot:

[mediawiki/extensions/SearchVue@master] Enhance the way the QuickView links searchResult to QuickView article

https://gerrit.wikimedia.org/r/894226

Testing notes for checking in wmf.26:

Search for water