1275930 - [e10s] InputContext shouldn't be updated until editor gets focus actually

Status: RESOLVED FIXED

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

Description

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

Currently, when focus is moving to an editor, IMEStateManager sets IMEState (enable, password) before editor actually gets focus. This *might* mean that if native IME tries to query contents when IME context is enabled, the query always fail or retrieve previous focused contents. Anyway, if it occurs, native IMEs, especially TIPs, behave odd.

Anyway, this may cause shuffling the order of nsIWidget::SetInputContext() and nsIWidget::NotifyIME() of NOTIFY_IME_OF_FOCUS.

PBrowser.SetInputContext() is async:
https://dxr.mozilla.org/mozilla-central/rev/8d0aadfe7da782d415363880008b4ca027686137/dom/ipc/PBrowser.ipdl#339

but PBrowser.NotifyIMEFocus() is sync because it needs result:
https://dxr.mozilla.org/mozilla-central/rev/8d0aadfe7da782d415363880008b4ca027686137/dom/ipc/PBrowser.ipdl#199-201

I think that SetInputContext() should be sync and shouldn't be used if editor will gets focus. Then, we can reduce the IPC cost and get rid of the bad order calls.

Comment 1

[Andrew Overholt [:overholt]]

What's the urgency here, Masayuki?

Comment 2

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

Not so urgent, but I'd like to fix this when I have much time.

Comment 3

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

Must have already been fixed by bug 1349255 and refactoring of IMEStateManager (I forgot the bug# though) after that.

Now, sending IME focus notification asynchronously with content cache so that when IME gets focus, ContentCacheParent has enough information for any query.