1284415 - [TSF][e10s] TSFTextStore should include expected result of dispatched KeyboardEvents

Status: NEW

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

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

TSFTextStore starting to cache whole contents during at least a composition (bug 1224994). The cache is updated by every modify request from TSF (e.g., InsertTextAtSelection(), SetText()). However, this doesn't include the result of KeyboardEvents which are not handled by TSF/TIP.

For example, when user types following steps quickly:

1. Commit "あい"
2. Type Backspace
3. Start composition with "う"

The cache could be "あいう" (depending on the timing between user input and handled by the remote process), not "あう". This might cause unexpected behavior with TSF if TIP uses surrounding text especially when modified characters are a part of new composition with SetSelection() call.

But emulating KeyboardEvent is difficult to notify TSF of text changes if the default action is canceled by web apps. So, if we do this, we need additional notifications from content, probably.

Comment 1

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

I meant that if web apps prevent default action of some KeyboardEvents, it causes odd behavior with TSF. But it's not major case than usual (expected) cases. So, I think that in e10s mode, widget should emulate expected behavior by TSF as far as possible and notify actual result with notifications later.

Comment 2

[Jim Mathies [:jimm]]

Hey Masayuki, How serious is this?

Comment 3

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

Not so serious but I'd like to fix this as soon as possible (but probably, not easy).

Comment 4

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

Fortunately, fixing bug 1224994 makes TSF with e10s really stable. Therefore, this bug's priority became lower than when I filed this bug.

Unfortunately, I have some trouble for fixing this bug. For example, when Ctrl + Backspace is pressed, ContentCacheInParent should remove a word before current selection.  Simply, it's very difficult to emulate such complicated behavior and too bad to implement such function with different path.  Additionally, if the default action is replaced or prevented by web apps, how can we notify widget of text change ranges? Merging actual changed range and expected range is enough? I need to dig this issue deeper...

Although, a possible way is, we should support only simple cases, i.e., inputting a character, Backspace and Delete.  That means we hide this bug in most cases, but should we do that? Since I don't see any symptom caused by this bug.

Comment 5

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

Moving all open keyboard/IME handling bugs to DOM: UI Events & Focus Handling component.