Closed Bug 1396725 Opened 7 years ago Closed 7 years ago

Can't activate input method for a content process sometimes

Categories

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

57 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla57
Tracking Status
firefox57 --- fixed

People

(Reporter: lilydjwg, Assigned: masayuki)

References

Details

(Keywords: inputmethod)

Attachments

(3 files)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20170902100317

Steps to reproduce:

Browse normally.

More Details:
I'm on Arch Linux 64bit, Firefox nightly (official build), with fcitx.


Actual results:

Suddenly I find that I can't activate my input method in tabs that belongs to one content process. Other tabs (or the browser UI) belongs to other processes continue to work. Killing that process then reloading the pages works.


Expected results:

I should be able to activate my input method as normal.
Component: Untriaged → Widget: Gtk
Keywords: inputmethod
OS: Unspecified → Linux
Product: Firefox → Core
When you meet this bug again, please get log files with following steps:

0. Open a page which has input filed in a broken tab (e.g., https://w3c.github.io/uievents/tools/key-event-viewer.html).
1. Open "about:networking" (and agree with the warning) in new tab.
2. Click "Logging" in the left pane.
3. Specify _full_ path to log file with the input field of "Current Log File:", then, click "Set Log File".
4. Set "IMEStateManager:5,ContentCacheWidgets:5,nsGtkIMModuleWidgets:5,sync" to the input field of "Current Log Modules:", then, click "Set Log Modules".
5. Click "Start Logging".
6. Switch to the tab of #0.
7. Click an input field in the tab to focus it.
8. Switch back to the "about:networking" tab.
9. Click "Stop Logging".
10. Then, attach 2 log files to this bug (use "Attach File" in this page), one is foo-main.nnnn, the other is foo-child.nnnn. "foo" is what you specified at #3. "nnnn" is process ID which you can see in the tooltip of each tab.

Note that please do not type anything your privacy data (like password) during logging it (i.e., #5~#9) since all key inputs via IME are recorded in foo-main.nnnn.
Flags: needinfo?(lilydjwg)
Attached file child process log
Flags: needinfo?(lilydjwg)
Attached file main process log
I've attached the log files.

I switched to that tab, and tried to input some "a", and tried to toggle the input method and type some "a" a couple of times. I use Ctrl-space to toggle my input method.
Two new things:

1. the issue happened after I switched from another window to the firefox window
2. I pressed alt two times in that tab (the menu bar showed up and then disappeared as expected), and I could activate the input method again

I can't reproduce it on purpose though.
Thank you for the log. The child process log tells us what is the problem:

> [Main Thread]: I/IMEStateManager OnChangeFocus(aPresContext=0x0x7ff0ad264800, aContent=0x0x7fef1d1a7320, aCause=CAUSE_UNKNOWN)
> [Main Thread]: I/IMEStateManager OnChangeFocusInternal(aPresContext=0x0x7ff0ad264800 (available: true), aContent=0x0x7fef1d1a7320 (TabParent=0x(nil)), aAction={ mCause=CAUSE_UNKNOWN, mFocusChange=FOCUS_NOT_CHANGED }), sPresContext=0x(nil) (available: false), sContent=0x(nil), sWidget=0x0x7ff0cc629400 (available: true), sActiveTabParent=0x(nil), sActiveIMEContentObserver=0x(nil), sInstalledMenuKeyboardListener=true
> [Main Thread]: I/IMEStateManager GetNewIMEState(aPresContext=0x0x7ff0ad264800, aContent=0x0x7fef1d1a7320), sInstalledMenuKeyboardListener=true
> [Main Thread]: D/IMEStateManager   GetNewIMEState() returns DISABLED because menu keyboard listener was installed
> [Main Thread]: I/IMEStateManager SetIMEState(aState={ mEnabled=DISABLED, mOpen=DONT_CHANGE_OPEN_STATE }, aContent=0x0x7fef1d1a7320 (TabParent=0x(nil)), aWidget=0x0x7ff0cc629400, aAction={ mCause=CAUSE_UNKNOWN, mFocusChange=GOT_FOCUS }, aOrigin=ORIGIN_CONTENT)
> [Main Thread]: I/IMEStateManager SetInputContext(aWidget=0x0x7ff0cc629400, aInputContext={ mIMEState={ mEnabled=DISABLED, mOpen=DONT_CHANGE_OPEN_STATE }, mHTMLInputType="text", mHTMLInputInputmode="", mActionHint="", mInPrivateBrowsing=false }, aAction={ mCause=CAUSE_UNKNOWN, mAction=GOT_FOCUS }), sActiveTabParent=0x(nil)
> [Main Thread]: I/IMEStateManager OnFocusInEditor(aPresContext=0x0x7ff0ad264800, aContent=0x0x7fef1d1a7320, aEditorBase=0x0x7fef2196b540), sPresContext=0x0x7ff0ad264800, sContent=0x0x7fef1d1a7320, sActiveIMEContentObserver=0x(nil)

sInstalledMenuKeyboardListener=true is odd. This is set to true when menu bar becomes active or a popup menu is open. However, I guess that your GUI does not match with this situation. I also experienced this bug when I was using twitter.com (unfortunately, I cannot reproduce it anymore even in current twitter.com).

So, the child process believes that keyboard event should be handled by menubar or popup menus when you meet this symptom. For workaround, please press Alt or Escape key to "inactivate" menubar or to "close" popup menu.
Ah, I might get the reason why it's true without menubar active nor popup menus.
Assignee: nobody → masayuki
Status: UNCONFIRMED → ASSIGNED
Component: Widget: Gtk → Event Handling
Ever confirmed: true
OS: Linux → All
Hardware: Unspecified → All
Comment on attachment 8905511 [details]
Bug 1396725 - IMEStateManager doesn't need to manage whether menu keyboard listener is installed in different process

https://reviewboard.mozilla.org/r/177314/#review182518

::: commit-message-d8e23:16
(Diff revision 1)
> +unavailable in a remote process.
> +
> +Current approach must be wrong.  IMEStateManager should manage menu keyboard
> +listener state only in the process which the listener is installed in.  Then,
> +when menu keyboard listener is uninstalled, IMEStateManager needs to restore
> +the latest input context in the remote process without the remote process.

"in the remote process without the remote process" doesn't look right.
Attachment #8905511 - Flags: review?(bugs) → review+
Comment on attachment 8905511 [details]
Bug 1396725 - IMEStateManager doesn't need to manage whether menu keyboard listener is installed in different process

https://reviewboard.mozilla.org/r/177314/#review182518

> "in the remote process without the remote process" doesn't look right.

Hmm, "without asking the remote process".
Pushed by masayuki@d-toybox.com:
https://hg.mozilla.org/integration/autoland/rev/e7bf1efbaa59
IMEStateManager doesn't need to manage whether menu keyboard listener is installed in different process r=smaug
https://hg.mozilla.org/mozilla-central/rev/e7bf1efbaa59
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.