Japanese IME input is not working Google spreadsheet

RESOLVED FIXED in Firefox 40



3 years ago
3 years ago


(Reporter: kuroweb, Assigned: masayuki)



Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox37 affected, firefox38 affected, firefox39 affected, firefox40 fixed, firefox-esr31 affected)


(Whiteboard: [parity-Chrome][parity-IE])


(3 attachments, 2 obsolete attachments)



3 years ago
Build identifier: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0

Steps to reproduce:

0. create clean profile.
1. open Google Drive and login google account.
2. create new spreadsheets.
3. turn on Japanese IME
4. input あああ
5. active window change firefox to other application.
6. re-active firefox window
7. input あああ

Actual results:

Expected results:


3 years ago
Keywords: inputmethod

Comment 1

3 years ago
I can reproduce all version of Firefox on Windows7 MSIME2010 and Ubuntu14.04 Mozc Fcitx.
And reproducible regardless of e10s or TSF.

Google Chrome41 and IE11 works fine.

Masayuki san, Is Google's failure?
Severity: normal → major
status-firefox37: --- → affected
status-firefox38: --- → affected
status-firefox39: --- → affected
status-firefox40: --- → affected
status-firefox-esr31: --- → affected
Ever confirmed: true
Flags: needinfo?(masayuki)
Keywords: jp-critical
OS: Windows 8.1 → All
Whiteboard: [parity-Chrome][parity-IE]
FYI: Except when you turn intl.tsf.force_enable true, TSF is disabled in e10s mode. So, this should be e10s's bug (I cannot this bug without e10s).

I'm not sure if it's google's failure, but perhaps, ours.
Flags: needinfo?(masayuki)
comment #0 is on TSF mode.

If using IMM32 mode, you cannot input any character even if turning off IME after step 5.  Then, after IME blur (focus awesome bar), you can input character by IME.

Also, If using IMM32 mode, behavior is very very strange

- Step
1. focus A1 cell
2. input あああ
3. focus B1 cell
4. input いいい

- Result
Candidate window is top-level of screen and input characters (by step 4) isn't appeared in cell.  After hit [Enter] for committing string, you can input character by IME.
Oops, I retry to test the STR, I reproduce this both TSF/IMM without e10s.

Looks like that the editable cell is made by setting contenteditable="true". However, our focus management fails to set proper IME state when the cell getting focus.
When I double-click on a cell immediately after open a spreadsheet, IME is kept disabled. However, the log of IMEStateManager looks like working fine. I'll investigate what occurs on focusing cell.

I guess that root cause could be same as the reported bug.
Oh, I found odd log...

> 0[1011140]: ISM: IMEStateManager::OnFocusInEditor(aPresContext=0x22f73c00, aContent=0x29849150, aEditor=0x2949a4f0), sPresContext=0x22f73c00, sContent=0x29849150, sActiveIMEContentObserver=0x0
> 0[1011140]: ISM: IMEStateManager::CreateIMEContentObserver(aEditor=0x2949a4f0), sPresContext=0x22f73c00, sContent=0x29849150, sActiveIMEContentObserver=0x0, sActiveIMEContentObserver->IsManaging(sPresContext, sContent)=false
> 0[1011140]: ISM:   IMEStateManager::CreateIMEContentObserver() is creating an IMEContentObserver instance...
> 0[1011140]: ISM: IMEStateManager::OnChangeFocus(aPresContext=0x22f73c00, aContent=0x0, aCause=CAUSE_UNKNOWN)
> 0[1011140]: ISM: IMEStateManager::OnChangeFocusInternal(aPresContext=0x22f73c00, aContent=0x0, aAction={ mCause=CAUSE_UNKNOWN, mFocusChange=FOCUS_NOT_CHANGED }), sPresContext=0x22f73c00, sContent=0x29849150, sActiveIMEContentObserver=0x25181f80
> 0[1011140]: ISM: IMEStateManager::NotifyIME(aMessage=REQUEST_TO_COMMIT_COMPOSITION, aWidget=0xebdf000), composition=0x0, composition->IsSynthesizedForTests()=false
> 0[1011140]: ISM: IMEStateManager::DestroyIMEContentObserver(), sActiveIMEContentObserver=0x25181f80
> 0[1011140]: ISM:   IMEStateManager::DestroyIMEContentObserver(), destroying the active IMEContentObserver...
> 0[1011140]: ISM: IMEStateManager::GetNewIMEState(aPresContext=0x22f73c00, aContent=0x0), sInstalledMenuKeyboardListener=false
> 0[1011140]: ISM:   IMEStateManager::GetNewIMEState() returns DISABLED because no content has focus
> 0[1011140]: ISM: IMEStateManager::SetIMEState(aState={ mEnabled=DISABLED, mOpen=DONT_CHANGE_OPEN_STATE }, aContent=0x0, aWidget=0xebdf000, aAction={ mCause=CAUSE_UNKNOWN, mFocusChange=LOST_FOCUS })
> 0[1011140]: ISM:   IMEStateManager::SetIMEState(), calling nsIWidget::SetInputContext(context={ mIMEState={ mEnabled=DISABLED, mOpen=DONT_CHANGE_OPEN_STATE }, mHTMLInputType="", mHTMLInputInputmode="", mActionHint="" }, aAction={ mCause=CAUSE_UNKNOWN_CHROME, mAction=LOST_FOCUS })
> 0[1011140]: ISM: IMEEnabledStateChangedEvent::Run(), notifies observers of "ime-enabled-state-changed"

When I set focus to a cell in RDP and check the log from another computer, I see this log.

Strangely, it's disabled due to nobody has focus after normal (expected) focus handling.
Assignee: nobody → masayuki
Component: General → Event Handling
Product: Firefox → Core
Created attachment 8589031 [details] [diff] [review]
part.1 Don't reset IME enabled state after focus is changed by JS during setting focus

There are two bugs. One of them is fixed by this patch.

If a focus event handler of document sets focus to an editor, nsFocusManager::Focus() calls IMEStateManager::OnChangeFocus() with null as focused content. Then, IMEStateManager disables IME *after* the editor finishes enabling IME.

So, if focus is moved to another element during running nsFocusManager::Focus(), it shouldn't call IMEStateManager::OnChangeFocus().
Attachment #8589031 - Flags: review?(enndeakin)
Created attachment 8589035 [details] [diff] [review]
part.2 nsHTMLEditor should accept composition events even while there is no active editing host but it has composition

Only with the part.1, we meet MOZ_ASSERT() at activating window. It's here:

TextComposition::mIsComposing is true only while focused editor has focus. However, nsHTMLEditor fails to receive composition events during nsFocusManager handling activating a window (It's not problem in normal cases, but focus event handler of document can change focused element and it may cause requesting to commit composition to IME).

But fortunately, there can be only one composition on a top level window. Therefore, if nsHTMLEditor has composition (mComposition isn't nullptr), nsHTMLEditor::IsAcceptableInputEvent() should always return true for composition events if mComposition isn't nullptr. Then, we can guarantee that all composition events is always handled by an editor even if it has lost focus.
Attachment #8589035 - Flags: review?(ehsan)
Created attachment 8589037 [details] [diff] [review]
part.1 Don't reset IME enabled state after focus is changed by JS during setting focus

Oops, sorry. I posted different bug's patch. Please see the previous patch's comment for the detail.
Attachment #8589031 - Attachment is obsolete: true
Attachment #8589031 - Flags: review?(enndeakin)
Attachment #8589037 - Flags: review?(enndeakin)
Created attachment 8589038 [details] [diff] [review]
part.2 nsHTMLEditor should accept composition events even while there is no active editing host but it has composition

Sorry for the spam. I posted different bug's patch. Please see the previous patch's comment for the detail.
Attachment #8589035 - Attachment is obsolete: true
Attachment #8589035 - Flags: review?(ehsan)
Attachment #8589038 - Flags: review?(ehsan)

Ah, and please ignore the part of IMEStateManager, I just fixes a missing case of logging code found at debugging this bug.
Is this a regression?

Comment 13

3 years ago
Created attachment 8589070 [details]
testcase of the patch part1

Regression window using testcase of the patch part1:

triggered by: Bug 178324


3 years ago
Attachment #8589038 - Flags: review?(ehsan) → review+
Attachment #8589037 - Flags: review?(enndeakin) → review+
I don't think that this is so critical because this occurs only after switching from another application and there is composition string before that. I think that this isn't so usual case. Additionally, the case to reproduce this bug is very tricky. Typically, web developers don't move focus from focus event handler of document.
Keywords: jp-critical
Actually, since 2002, this hasn't been reported for about 12 years!
Last Resolved: 3 years ago
status-firefox40: affected → fixed
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
You need to log in before you can comment on or make changes to this bug.