- Environment Linux + GTK2 or GTK3 - Step 1. Focus comment field of a article on facebook 2. Turn on IME then input any character - Result Cannot input any character. Also, when set focus, placeholder into comment is blink.

maybe, selection change is called unfortunately.

I can reproduce the problem on Ubuntu14.04 32bit + fcitz-Mozc STR 1. Focus comment field of a article on facebook 2. Turn on IME then input any character 3. If not reproduce, Erase all character by [BS] key, and input any character Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d295209feea1&tochange=1dc5cbdf0dd8 Regressed by: 1dc5cbdf0dd8 Makoto Kato — Bug 1166323 - Remove IME sequence number. r=masayuki,nchen

Facebook comment field seems to use Selection::extend by Javascript. So additional OnSelectionChange is fired. When using ibus-pinyin, composition event is sent repeatedly (ResetIME causes composition signal and OnSelectionChange occurs from JS? again, then ...).

Isn't this reproduced in non-e10s mode? If so, how nsGtkIMModule ignores the selection change in non-e10s mode?

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #4) > Isn't this reproduced in non-e10s mode? If so, how nsGtkIMModule ignores the > selection change in non-e10s mode? Yes. this is only on e10s. I should create test case for this before fixing this.

Humm, this is async issue... Facebook's JS seems to use Selection.extend on compositionstart. So when non-e10s mode, mCompositionState is StartDispatched on OnSelectionChanged. So ResetIME isn't called. But when e10s mode, mCompositionState isn't StartDispatched on OnSelectionChanged due to async. So ResetIME is called.

Thank you for your investigation. That sounds interesting. For long term fix, i.e., ideal fix, must need synchronous event dispatch at least for NS_COMPOSITION_START. If we don't take the approach, we may have two ways: 1. If the selection "offset" isn't changed actually, we should discard the selection change notification in IMEContentObserver. 2. Otherwise, we should cancel selection change notification at first NS_COMPOSITION_CHANGE event in TabParent.

(On Windows the TC behaves exactly the same way in all browsers - including Fx nightly with E10S enabled)

The testcase doesn't work with GTK nor TSF.

Hmm, do you still reproduce this bug on Facebook?

Let's mark selection change notifications if they occurred during composition.

If IMContextWrapper receives a selection change notification occurred without composition but IME is composing, IMContextWrapper shouldn't commit the composition and put off to notify IME of selection change by compositionend. The deferred notification should correct the surrounding text if it was stored by IME.

This is hacky patch and doesn't work well in the testcase if you set caret offset > 0. I'll file a bug for fixing the other cases in 45. But at least for Facebook (although, it might be changed by Facebook side already), this should "prevent" this bug.

FYI: > 1. If the selection "offset" isn't changed actually, we should discard the selection change notification in IMEContentObserver. > 2. Otherwise, we should cancel selection change notification at first NS_COMPOSITION_CHANGE event in TabParent. #1 was already fixed by bug 1189396, the reason which I cannot reproduce this bug on Facebook may be the fix of bug 1189396.

Comment on attachment 8678157 [details] [diff] [review] part.1 SelectionChangeDataBase and TextChangeDataBase should have a flag which indicates whether the change occurred during composition or not IsOccurredDuringComposition() sounds odd. Why not just OccurredDuringComposition()

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #11) > Hmm, do you still reproduce this bug on Facebook? No, they seems to fix this.

(In reply to Makoto Kato [:m_kato] from comment #18) > (In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #11) > > Hmm, do you still reproduce this bug on Facebook? > > No, they seems to fix this. Hmm, odd I cannot reproduce this on actual Facebook page. Do you reproduce on your home's comment field for an article posted by another person?

https://hg.mozilla.org/integration/mozilla-inbound/rev/760b56778e5a427026377c5ac2170f56917a672c Bug 1184890 part.1 SelectionChangeDataBase and TextChangeDataBase should have a flag which indicates whether the change occurred during composition or not r=smaug https://hg.mozilla.org/integration/mozilla-inbound/rev/e23949bd2c042aa175f029112a26114c2ea6b558 Bug 1184890 part.2 IMContextWrapper shouldn't commit composition when a selection change notification occurred before starting current composition r=m_kato https://hg.mozilla.org/integration/mozilla-inbound/rev/92d383d8d282e9fb35302836f9e44717c2d1d4cc Bug 1184890 part.3 TSFTextStore shouldn't commit composition when a selection change notification occurred before starting current composition r=m_kato

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #19) > (In reply to Makoto Kato [:m_kato] from comment #18) > > (In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #11) > > > Hmm, do you still reproduce this bug on Facebook? > > > > No, they seems to fix this. > > Hmm, odd I cannot reproduce this on actual Facebook page. Do you reproduce > on your home's comment field for an article posted by another person? At that time, I could reproduce by comment to my article and others. Maybe, I think they change their script as workaround or other fix.

https://hg.mozilla.org/mozilla-central/rev/760b56778e5a https://hg.mozilla.org/mozilla-central/rev/e23949bd2c04 https://hg.mozilla.org/mozilla-central/rev/92d383d8d282