Page MenuHomePhabricator

[WtC-M2] [SNL] Codex Lookup implementation of SpellingVariantInput drops input
Closed, ResolvedPublic

Description

Since replacing Wikit's Lookup component implementation of SpellingVariantInput in new-lexeme-special-page with Codex's (b8a180d915b80f0ba089cdef465e7bc21ffd4565), the input swallows some characters (see draft changes to cypress tests).

It seems that the first character(s) typed, and sometimes characters typed quickly, confuse the input. Also highlighting the text in the input and trying to write over it reproduces the issue.

Acceptance Criteria

  • The codex SpellingVariantInput implementation functions well and does not swallow inputs.

Event Timeline

ArthurTaylor renamed this task from Codex Lookup implementation of SpellingVariantInput drops input to [WtC-M2] [SNL] Codex Lookup implementation of SpellingVariantInput drops input.Tue, Nov 12, 8:41 AM

@ArthurTaylor and I looked into this, and eventually arrived at some promising-sounding investigation results. The most important is that in this code:

<cdx-lookup
    v-model:selected="selection"
    :placeholder="messages.getUnescaped(
        'wikibaselexeme-newlexeme-lemma-language-placeholder-with-example',
        config.placeholderExampleData.spellingVariant
    )"
    :search-input="searchInput"
    :menu-items="menuItems"
    :input-value="props.modelValue"
    @input="onInput"
    @update:selected="onOptionSelected"
>

:search-input="searchInput" appears to have no effect – the Wikit component had this prop, but the Codex component does not. By comparison, the ItemLookup component sets v-model:input-value="searchInputWrapper". Both the ItemLookup and the SpellingVariantInput have two props of their own, for the value and the search input, but ItemLookup binds Codex’s value to the search input prop, whereas SpellingVariantInput binds Codex’s value to its own value and the search input prop goes nowhere. We want to try to bring SpellingVariantInput closer to ItemLookup – bind Codex’s value to the search input prop, and manage the SpellingVariantInput’s value separately (with lastSelectedOption and the update:modelValue event).

The above error was not reproducible in the dev entry point, which turns out to be because in the dev entry point we were still using Codex 1.14, whereas MediaWiki now ships Codex 1.16. After updating the new-lexeme-special-page repo to Codex 1.16, the error becomes reproducible in the dev entry point (and some tests start failing).

git bisect shows that the difference in behavior was introduced with Lookup: Ensure input event on selection has correct value (T378177). We still need to investigate what this means and if we need a fix in new-lexeme-special-page and/or in Codex.

Steps to reproduce:

(I can’t fully test these steps because npm is glacially slow for me, but they should work, I think.)