1301486 - Flash - The candidate window displayed at wrong position when inputting some CCJK characters

Status: RESOLVED INCOMPLETE

(External Software Affecting Firefox Graveyard :: Flash (Adobe), defect)

Description

[Jeromie Clark]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36

Steps to reproduce:

Platform:
Windows 10 - Japanese - Bug 
Windows 10 - Korean - Bug 
Windows 10 - Simp Chinese - Bug 
Windows 10 - Trad Chinese - Bug

FAIL: Win10_14342 OS + Firefox + 22.0.0.175 build
FAIL: Win10_14342 OS + Firefox + 21.0.0.122 build (This is the injection build)
PASS: Win10_14342 OS + Firefox + 21.0.0.121 build
PASS: Win10_14342 OS + IE & Edge & Chrome & Opera + 22.0.0.175 build

Problem: 
The candidate window displayed at wrong position when input some CCJK characters. 
And the second candidate window also displayed at wrong position.
Method:
1.Install FP 22.0.0.175 on Win10.
2.Launch Firefox and navigate to "http://ats.macromedia.com/Players/ATS/ATS10AS3/Shipping/ATS.html"
3.Run a case under Localization All> Localization>IME_Smoke
4.Change input language to Chinese-Simplified/Traditional/Korean/Japanese
5.Enter characters into input area. For example, change the IME to Quick/Changjie input “ji”.
6.Press "1"

Developer Analysis: 

I think this issue should be escalated to Mozilla. It is an injection of [Flash] CL# 38154 that was originally requested by Mozilla for having the control of IME in protected mode of Firefox. Either by rollback the fix or launch Firefox in unprotected mode used to resolve the bug.

And it looks developing version of Firefox(Nightly build) having some progress for the first candidate window. However, there is one remaining issue that Bo Tang found. 

The second candidate window is still located in uncomfortable position for its users. And this time, the workaround, rollback the fix or launch in unprotected mode, is not working for the second candidate window in the Nightly build of Firefox.

So, I think we may need to file this bug and let Mozilla fix it.


Actual results:

Result:

For Step5, The first candidate window displayed at wrong position. Please refer to the attached screenshot "FF_firstcandidate window.png"

For Step6, The second candidate window displayed at wrong position. Please refer to the attached screenshot "FF_second candidate_tw.png"




Expected results:

Expect:
The position of the candidate window should be displayed well when input any characters.

Comment 1

[Jeromie Clark]

Attachment: 1_FF_firstcandidate_window.png

Comment 2

[Jeromie Clark]

Attachment: 2_FF_second_candidate_tw.png

Comment 3

[Jeromie Clark]

Attachment: 3_win10_second_candidate_window.png

Comment 4

[Jeromie Clark]

Attachment: 4_Screenshot_(1).png

Comment 5

[Jeromie Clark]

Attachment: 5_Screenshot_(2).png

Comment 6

[Jeromie Clark]

I accidentally provided an intranet link for the STRs. 

Here's a publicly accessible link: 
http://www.playercore.com/ats/ATS10AS3/Shipping/Manual/Localization/IME_Smoke/BasicInputViaOSK.swf

Comment 7

[Loic]

Makoto, could you help with these Asian IME issue?

Comment 8

[Makoto Kato [:m_kato]]

I have a question.

FLASHPLAYERPLUGIN_22_0_0_209 process's window (class name: GeckoFPSandboxChildWindow) doesn't handles WM_IME_COMPOSITION (all WM_IME_*) message well from Flash 21.  Why?

We supports window mode for 32-bit Flash.  So flash must handle IME messages to use inline input.

For windowless mode, our plugin process (plugin-containter.exe) hooks some Imm API to delegate to chrome process.  But when it is window mode's plugin, we don't hook these Imm API.

(If I should mail to Adobe's internal contact like some issues, I will send it and  discussion this)

Comment 10

[Max Song]

The reason Flash fails to handle IME events is it's getting NULL for IMEMsg_ImmGetContext in NPAPIHostProxy::DoImmGetContext when FP is running in protected mode. Is the function, IMEMsg_ImmGetContext, working asynchronously?

Comment 11

[Makoto Kato [:m_kato]]

What's IMEMsg_ImmGetContext?  Maybe, it is internal Flash code.  On x86 Flash, although we hook ImmGetContext API, we delegate to our chrome process if windowless and window class name is SWFlash_PlaceholderX only.

Comment 12

[Makoto Kato [:m_kato]]

When wmode is window, window (FLASHPLAYERPLUGIN_23_0_0_162)'s owner process seems to be FlashPlayerPlugin_23_0_0_162.exe.  So I think that Adobe has to call ImmGetContext on your process (FlashPlayerPlugin_23_0_0_162.exe).  But as long as I debug this, Adobe mistakes that ImmGetContext is called on our plugin process (plugin-container.exe).

So Adobe should call IMM APIs on same process that window is created when wmode=window.

Comment 13

[Makoto Kato [:m_kato]]

window name is GekcoFPSandboxChildWindow.

Comment 14

[Max Song]

Thanks for your comments. I verified your suggestion can fix the candidate window issue.

Comment 15

[Makoto Kato [:m_kato]]

(In reply to Max Song from comment #14)
> Thanks for your comments. I verified your suggestion can fix the candidate
> window issue.

Thanks, Max.  I am looking forward to releasing new version with its fix.

Comment 16

[Max Song]

The bug was fixed in the latest release, FlashPlyaer 24.0.0.186, and it works well on Firefox 50.1.0. However, the behavior on Firefox Nightly 53.0a1 is a bit different for the second candidate window. When I tested with Microsoft ChangJie, the second candidate window appears on the bottom-right of the screen. Is there anything that should be fixed further?

Comment 17

[Loic]

Max, did you test Nightly with e10s enabled and disabled?

Comment 18

[Max Song]

I've checked the issue with enabled and disabled of 'Enable multi-process Nightly' in General preferences menu, but the results were the same. The second candidate windows is located in the bottom-right area in the Nightly build.

Comment 19

[Makoto Kato [:m_kato]]

Even if I use 50.1.0 (x86) with Flash 24, IME inline editor doesn't work on windowed mode at first time.
Also, windowless mode works well.

STR
===
1. Launch Firefox x86 and Browse http://baseonmars.co.uk/bugs/wmode/
2. Focus text area into wmode = 'window'.
3. Input 'ああ' via Microsoft IME
4. Hit [space] key

RESULT
======
'ああ' isn't converted.

NOTE
====
After changing focus to windowless text box, it works well.


Max, does Adobe fix this correctly?

Comment 20

[Max Song]

What is the FlashPlayer version you're testing with? On FP 24.0.0.186(the latest), the test results of all 3 input contorls in your test page are working well to me.
Besides, do you mean that the candidate window is not appearing with FlashPlayer? The original issue was about the position of candidate window, but it seems more serious. Could you please elaborate your test environments?

Comment 21

[Makoto Kato [:m_kato]]

(In reply to Max Song from comment #20)
> What is the FlashPlayer version you're testing with? On FP 24.0.0.186(the

My test environment is
- Windows 10 x64 with the latest stable channel with Japanese locale
- Firefox 50.1.0 x86
- Flash version: 24.0.0.186
- Microsoft IME (Japanese)

> latest), the test results of all 3 input contorls in your test page are
> working well to me.
> Besides, do you mean that the candidate window is not appearing with
> FlashPlayer? The original issue was about the position of candidate window,

Yes.  candidate window isn't appearing when converting doesn't work. After changing focus to windowless text box, candidate window appears well even if windowed flash.

Comment 22

[Max Song]

Since I'm not a Japanese speaker, I don't understand what converting is. I just randomly input Japanese characters with space key in order to pop-up the candidate window, and it seems OK to me.
Is there any specific scenario to reproduce the issue? Honestly, I don't know how to type 'ああ'.

FYI, I'm also testing with Windows10 x64 with Japanese Microsoft IME.

Comment 23

[Makoto Kato [:m_kato]]

STR
===
1. Change default IME to Microsoft IME (JapanesE)
2. Launch Firefox x86 and Browse http://baseonmars.co.uk/bugs/wmode/
3. Focus text area into wmode = 'window'.
4. Push [ALT] +[~] to turn on Japnese IME
5. Push [a] to input 'あ'
6. Push [a] to input 'あ' again
7. Push [space] to convert 'ああ' (hiragana) to Kanaji

RESULT
======
'ああ' isn't converted.

Comment 24

[Makoto Kato [:m_kato]]

s/Kanaji/Kanji

Comment 25

[Max Song]

I've just checked this case following your instruction, and I found that the candidate window appears by second input of [Space] keys for wmode='window'. Then, the other windows present the same behaviors. Sometimes, windows for wmode='opaque' and 'transparent', can convert the text at once, but not always. I'm not sure if this was an injection of my fix. So, I may need to test with the older FP versions.

Comment 26

[Makoto Kato [:m_kato]]

After Firefox 55, we move to windowless as default for async-drawing.  But composition window's position is still invalid on 32bit windows.  (64bit works fine)

When I debug it using latest, Flash doesn't delegate ImmGetContext to plugin-container.exe.  To fix this, Adobe has to call ImmGetContext on plugin-container.exe instead of NPSWF32_29_0_0_140's process.

When on windowed mode, ImmGetContext should call on window producer's process.  But on windowless, it should be called on plugin-container's process.  Because we cannot detect passed HIMC is for plugin or not.

Max, do you still work for Flash?

Comment 27

[Makoto Kato [:m_kato]]

ni to jeclark instead.  This is Flash bug that ImmGetContext doesn't call on our process.

Comment 28

[Jeromie Clark]

Initial analysis shows that we've already moved this call into plugin-container.  Matt is digging into it to see if we can figure out why this is happening.

Comment 29

[u597032]

Adobe Flash is no longer supported.