Closed Bug 1275930 Opened 4 years ago Closed 6 months ago

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


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




Tracking Status
e10s + ---
firefox49 --- affected


(Reporter: masayuki, Unassigned)



(Keywords: inputmethod, 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:

but PBrowser.NotifyIMEFocus() is sync because it needs result:

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
tracking-e10s: --- → +
Priority: -- → P3
Component: Event Handling → User events and focus handling

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.

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.