1235573 - Multiple kanji character are inputed w/ windowless flash plugin on swf4

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Alice0775 White]

Build Identifier:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c29de223de2f8ba0b724ac910b7bacfdddbd2bc7
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0 ID:20151229060510

Multiple kanji character are imputed on windowless flash plugin.

I am using Windows7 x64 SP1 Home Premium + Flash Player 20.0.0.267.

I can reproduce the problem with the following IME.
* Microsoft IME, bundled with Windows7
* Microsoft Office IME 2010.

Steps To Reproduce:
1. Open http://emk.name/test/swftxt.html

2. Click text field of "swf4 windowed:" to focus
3. IME on
4. Type m o j i, converts it to "文字" and then hit ENTER

5. Click text field of "swf4 opaque:" to focus
6. IME on
7. Type m o j i , converts it to "文字" and then hit ENTER


Actual results:
文文文字字字 at step 7.

Expected Results:
文字 at step 7.


Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ad9fef2aa6cb6d263e439e12adf4cf4d90236484&tochange=c29de223de2f8ba0b724ac910b7bacfdddbd2bc7

Triggered by: Bug 1208944

Comment 1

[Alice0775 White]

fixed by backed out(54a19e8d57c4).

Comment 2

[Makoto Kato [:m_kato]]

ah, sorry. this isn't related to e10s

Comment 3

[Makoto Kato [:m_kato]]

swf4 on Flash is strange behavior.  When calling WM_IME_COMPOSITION with GCS_RESULTSTR, Flash will call DefWindowProc. (Other messages don't call DefWindowProc.) DefWindowProc generates WM_IME_CHAR and dispatch it to default IME window.  Since process is different, it will cause unexpected behavior.

Comment 4

[Alice0775 White]

FYI, swf6, swf7 and swf8 are also broken though the actual results is "文字文字".

Comment 5

[Makoto Kato [:m_kato]]

(In reply to Alice0775 White from comment #4)
> FYI, swf6, swf7 and swf8 are also broken though the actual results is "文字文字".

I cannot reproduce swf6+.  This issue depends on x64 or x86 and protected mode flash or not.

Comment 6

[Alice0775 White]

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0 : 32bit build on Windows7 64bit
protected mode flash : default enabled

Comment 7

[Alice0775 White]

And I can also reproduce on Windows10 64bit build 11082

https://hg.mozilla.org/mozilla-central/rev/29258f59e5456a1a518ccce6b473b50c1173477e
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0 ID:20160105030211

Comment 8

[Alice0775 White]

(In reply to Alice0775 White from comment #7)
> And I can also reproduce on Windows10 64bit build 11082
> 
> https://hg.mozilla.org/mozilla-central/rev/
> 29258f59e5456a1a518ccce6b473b50c1173477e
> Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
> ID:20160105030211

swf4 : 文文文字字字
swf6, swf7 and swf8 : 文字文字

Comment 9

[Makoto Kato [:m_kato]]

Thanks, Alice-san.

When posting WM_IME_COMPOSITION with GCS_RESULTSTR to Flash, Flash's render process calls ImmGetCompositionStringW on own process.  ImmGetCompositionStringW returns *LAST* committed string on this Flash's process.  So if windowed mode plugin already runs on same process, it can get a committed string that another windowed mode Flash handles the composition at finally.

This is a bug of Flash's protected mode.

So we shouldn't post GCS_RESULTSTR when Flash doesn't handle WM_IME_COMPOSITION with GCS_COMPSTR well.

Comment 10

[Makoto Kato [:m_kato]]

Attachment: Don't post GCS_RESULTSTR to plugin when it doesn't handle WM_IME_COMPOSITION correctly

Comment 11

[Makoto Kato [:m_kato]]

Comment on attachment 8704560 [details] [diff] [review]
Don't post GCS_RESULTSTR to plugin when it doesn't handle WM_IME_COMPOSITION correctly

When posting WM_IME_COMPOSITION with GCS_RESULTSTR to Flash, Flash will call ImmGetCompositionStringW to get committed string.  This API returns the *last* result of committed string. (HIMC is shared on plugins).

This problem is on protected mode.

You know, windowless mode Flash on protected mode calls IMM API on their render process.  Although this is a bug of Flash's protected mode, it can get committed data on windowed mode plugin unfortunately after using IME on windowed mode Flash.  Because both plugin objects run on same process.

So we shouldn't post GCS_RESULTSTR to plugin if plugin doesn't handle WM_IME_COMPOSITION well. (in other word, Flash runs on protected mode.)

Note: swf4 has another bug.  It can handle GCS_RESULTSTR only.  When handling GCS_RESULTSTR, it calls DefWindowProc.  Although DefWidnowProc generates WM_IME_CHAR, it generates charter twice.  So we shouldn't also post it to plugin.

Comment 12

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Comment on attachment 8704560 [details] [diff] [review]
Don't post GCS_RESULTSTR to plugin when it doesn't handle WM_IME_COMPOSITION correctly

Looks good to me except the name of mDisableIMECompositionEvent. Perhaps, mPluginDidNotHandleIMEComposition?

Comment 13

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/fdca1265183d

Comment 14

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/fdca1265183d