2003858 - Setting HTMLInputElement.value on input events behaves differently from Chrome with Swiftkey keyboard

Status: NEW

(Core :: DOM: Editor, defect)

Description

[Kagami Rosylight [:saschanaz] (they/them)]

Attachment: input.value example

On the attached file, focus on the input and tap 1 repeatedly on your on-screen keyboard.

On Chrome: The content is kept as 1 and no composition happens.
On Firefox: The content grows as the composition happens.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

InputEvent.data is the same as the composing string which may be different from HTMLInputElement.value. Then, how we can retarget the replacing range of the composition string? That's the main issue of this kind of handling.

On the other hand, in your STR, I guess the values are the same. If so, I think we don't track the replacing range since we use nsRange for each composition string clause and it's shrunken when all data of the Text is modified. Perhaps, EditorBase::ReplaceSelectionAsSubAction() should stop modifying the Text when the new value is same during composition.

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Odd, it's not reproducible with synthesized compositions. I guess IME commits composition with a text change notification or something.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

When HTMLInputElement.value is set, we notify TextControlState::SetValue() of the old value.
https://searchfox.org/firefox-main/rev/5a5b3741981250310f4327537f18879559779f9c/dom/html/HTMLInputElement.cpp#1752,1763-1766

Then, TextControlState::SetValue() does nothing if the old value is the same value as the new value.
https://searchfox.org/firefox-main/rev/5a5b3741981250310f4327537f18879559779f9c/dom/html/TextControlState.cpp#2574-2577,2591-2592,2594-2599

So, the testcase should work... Any ideas?

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Err, I misunderstood the report. So, the <input>.value should have only the latest composition value and it should be committed. Hmm, the expected behavior conflicts with the expectation of bug 1240336. So, I don't understand Chrome works as so now.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Odd, this testcase works fine on desktop, but on Fenix, indeed, the composition string is not overwritten by the setting value.

I think the last input value which is dispatched after compositionend whose inputType is "insertCompositionText" and data is the latest composition string should overwrite the <input>.value after committing the composition. However, the composition is not committed by the setting value.

Makoto-san, could you take a look?

Comment 6

[Makoto Kato [:m_kato]]

yep