Page MenuHomePhabricator

Pasted text in Wikidata search box disappear after pasting
Closed, ResolvedPublicBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

What happens?:

  • Items dropbox appears but the pasted text disappears

What should have happened instead?:

  • Items dropbox appears and the pasted text is visible in the search box

Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia):
Selection from https://www.wikidata.org/wiki/Special:Version

  • MediaWiki 1.45.0-wmf.6 (809f76d) 17. jun. 2025, 01:59
  • AdvancedSearch – (6225c26) 12. jun. 2025, 09:24

Other information (browser name/version, screenshots, etc.):

  • Firefox browser or Chromium browser

Event Timeline

And even if one repaste the text into the search field and press the search button one ends up on the front page instead of performing a search.

I can’t reproduce this – can you clarify what kind of paste you’re using? Ctrl+V, context menu, middle click, something else?

And even if one repaste the text into the search field and press the search button one ends up on the front page instead of performing a search.

That would be T397506.

I was able to reproduce it only if I pasted it in the second it takes for the dropdown to appear. And it seems my reflexes are not sharp enough to reproduce it a second time.

I was copy-pasting with the middle mouse button on a Linux system. If I start at https://www.wikidata.org/wiki/Wikidata:Main_Page and copy-paste, then the text shortly appears before the "Items" dropdown" erases it.

When I then copy-paste it again and press Search I end up with the https://phabricator.wikimedia.org/T397506 problem.

If I use Ctrl+v I can paste the text fine, - but still has the T397506 problem.

I think what’s happening here is that some text ends up in the input while the ScopedTypeaheadSearch ResourceLoader module is loading, and then when we mount the new search, we don’t copy over the value of the old input. (Vector fixes this here, where search is the input[name=search] of the pre-existing search form.)

Change #1166396 had a related patch set uploaded (by Arthur taylor; author: Arthur taylor):

[mediawiki/extensions/Wikibase@master] Populate initial input in ScopedTypeaheadSearch from HTML input

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

Change #1166396 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Populate initial input in ScopedTypeaheadSearch from HTML input

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

Hm, the fix should be deployed now, but middle-click paste is still not working on Wikidata :/

On localhost, I can reproduce a similar issue: the fix works if the search will take a moment to initialize (e.g. after a Ctrl+F5, while ResourceLoader is still loading), but doesn’t work if the search is ready to go immediately (after a normal reload, or after waiting long enough after a Ctrl+F5). On Wikidata, the “will take a moment to initialize” behavior is harder to trigger because the site is more optimized, but overall it seems to be similar.

Maybe we need to wait a moment (a microtick?) between registering the focus event and replacing the search, so that the middle-click can still go through?

I find the middle-click paste and search now works. Thanks.

I can still reproduce the middle-click issue…

I can still reproduce the middle-click issue…

Filed separately at T399541: First middle-click paste does not work on Vector 2022 search inputs as it turns out to also affect non-Wikidata search.

Thanks so much Lucas!

As this is an edge case and occurring across all Vector 2022 search inputs I think we can deprioritise the middle click issue for now and keep this ticket closed