Wondering if @Sarai-WMDE or @Michael have an idea what's going on here.

Mh, one thing that is happening at that moment, is that it loads more results. But I have to spend time looking into the code in order to figure out why that would reset the keyboard position. That is definitively not supposed to happen. Also, I think that used to work correctly?

Interestingly, I can still reproduce this issue on the Codex TypeaheadSearch Wikidata demo, so it doesn’t seem to be limited to Wikit.

In T324743#8460301, @Lucas_Werkmeister_WMDE wrote:

Interestingly, I can still reproduce this issue on the Codex TypeaheadSearch Wikidata demo, so it doesn’t seem to be limited to Wikit.

Could you share the steps with which you reproduced this on Codex? I tried it, but on Codex it works as expected (highlighted item does not reset when receiving more results)

I would say that this is a wikit problem, because I can also reproduce it at https://query.wikidata.org/querybuilder/

Did we cause this with some recent change, or did we just somehow fail to notice it till now?

(Notably, that also means that this affects both the Vue 2 as well the Vue 3 version of the Wikit Lookup)

In T324743#8460492, @Michael wrote:

In T324743#8460301, @Lucas_Werkmeister_WMDE wrote:

Interestingly, I can still reproduce this issue on the Codex TypeaheadSearch Wikidata demo, so it doesn’t seem to be limited to Wikit.

Could you share the steps with which you reproduced this on Codex? I tried it, but on Codex it works as expected (highlighted item does not reset when receiving more results)

Typing “e” and then using the “down” key; it seems to be more reproducible when I quickly press the “down” key or even hold it down. Screencast (Phabricator wouldn’t accept it as an upload): https://tmp.lucaswerkmeister.de/T324743.webm

Ah, no. This is different in so far as that the Codex Lookup is intended to loop around to the beginning when you step past the last element and footer. As far as I can see, this does not reset the scroll position purely when more elements are loaded, right?

Looking at things, I think this was introduced by commit wmde/wikit@a7e2cd540a, specifically when it changed OptionsMenu.vue -> watch -> menuItems. Though that would imply that this exists since quite a while ago? Also, it looks so obvious to me now, that I'm surprised that we did not notice it back then.

Task breakdown notes:

• T324743#8460756 identifies the problem.
  • We should make sure that we don’t introduce a regression about the behavior that was fixed in that commit: closing and reopening the menu.
• To test the fix within Wikit, it would be nice to add an example to the storybook (or somewhere else?) that has load-more behavior.
• We’ll need to make new releases of Wikit (master and next branches) and use the new versions in Special:NewLexeme and query builder.

This is a Wikit issue that has been solved in this PR, for the issue to be solved in new Lexeme a new Wikit release needs to be made and the version needs to be updated in the new lexeme project.

• Wikit PR: https://github.com/wmde/wikit/pull/656
• Wikit Pre-release PR for vue2x: https://github.com/wmde/wikit/pull/657
• Wikit Prerelease Link for vue2.x: https://github.com/wmde/wikit/releases/tag/v2.1.0-alpha.15
• Wkit Pre-release PR for vue3.x (next branch): https://github.com/wmde/wikit/pull/659
• Wikit Prerelease Link for vue3.x (next): https://github.com/wmde/wikit/releases/tag/v3.0.0-alpha.10
• Updating the Wikit version in new-lexeme: https://github.com/wmde/new-lexeme-special-page/pull/356
• Bump special-new-lexeme on WikibaseLexeme: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikibaseLexeme/+/871320

Change 871320 had a related patch set uploaded (by Guergana Tzatchkova; author: Guergana Tzatchkova):

[mediawiki/extensions/WikibaseLexeme@master] Bump new-lexeme to include new version of wikit

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

Change 871320 merged by jenkins-bot:

[mediawiki/extensions/WikibaseLexeme@master] Bump new-lexeme to include new version of wikit

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

Thanks all!

This is looking good to me :)

Just a heads-up that the issue can still be reproduced in the context of the Query Builder. Maybe this is already in progress, but the WiKit version should also be updated in that project.

In T324743#8504942, @Sarai-WMDE wrote:

Just a heads-up that the issue can still be reproduced in the context of the Query Builder. Maybe this is already in progress, but the WiKit version should also be updated in that project.

Thanks for bringing this up @Sarai-WMDE , yes indeed this has to be updated but I didn't because the tasks were not part of our sprint and I wasn't sure about the priorities. When the tasks are created I can replace the version.. Or i can create the tasks if needed but I need to know in which Sprint to pull them in :)

Here's a subtask to update the WiKit version in use by the Query Builder, which will fix the lookup navigation issues displayed there: T326543: Query Builder: Fix lookup navigation issue

In T324743#8508566, @Sarai-WMDE wrote:

Here's a subtask to update the WiKit version in use by the Query Builder, which will fix the lookup navigation issues displayed there: T326543: Query Builder: Fix lookup navigation issue

Thanks!!! @Sarai-WMDE