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

NEW
Unassigned

Status

()

Core
Event Handling
P3
normal
2 years ago
a year ago

People

(Reporter: masayuki, Unassigned)

Tracking

({inputmethod})

Trunk
inputmethod
Points:
---

Firefox Tracking Flags

(e10s+, firefox49 affected)

Details

(Whiteboard: btpp-followup-2016-07-05)

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.
What's the urgency here, Masayuki?
Flags: needinfo?(masayuki)
Whiteboard: btpp-followup-2016-07-05
Not so urgent, but I'd like to fix this when I have much time.
Flags: needinfo?(masayuki)
Summary: InputContext shouldn't be updated until editor gets focus actually → [e10s] InputContext shouldn't be updated until editor gets focus actually
See Also: → bug 1286117

Updated

a year ago
tracking-e10s: --- → +
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.