Closed Bug 1275930 Opened 4 years ago Closed 6 months ago
Context shouldn't be updated until editor gets focus actually
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?
Not so urgent, but I'd like to fix this when I have much time.
Summary: InputContext shouldn't be updated until editor gets focus actually → [e10s] InputContext shouldn't be updated until editor gets focus actually
Component: Event Handling → User events and focus handling
Status: NEW → RESOLVED
Closed: 6 months ago
Depends on: 1349255
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.