Open Bug 1301486 Opened 3 years ago Updated Last year

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

Categories

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

defect
Not set

Tracking

(Not tracked)

People

(Reporter: jeclark, Assigned: m_kato, NeedInfo)

References

Details

(Keywords: inputmethod)

Attachments

(5 files)

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.
Attached image 4_Screenshot_(1).png
Attached image 5_Screenshot_(2).png
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
Makoto, could you help with these Asian IME issue?
Component: Untriaged → Plug-ins
Flags: needinfo?(m_kato)
Keywords: inputmethod
Product: Firefox → Core
Version: 22 Branch → 48 Branch
Assignee: nobody → m_kato
Flags: needinfo?(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)
Flags: needinfo?(jeclark)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Duplicate of this bug: 1260013
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?
Flags: needinfo?(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.
Flags: needinfo?(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.
Flags: needinfo?(maxsong)
window name is GekcoFPSandboxChildWindow.
Thanks for your comments. I verified your suggestion can fix the candidate window issue.
(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.
Flags: needinfo?(maxsong)
Flags: needinfo?(jeclark)
Component: Plug-ins → Flash (Adobe)
Product: Core → External Software Affecting Firefox
Version: 48 Branch → unspecified
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?
Flags: needinfo?(m_kato)
Max, did you test Nightly with e10s enabled and disabled?
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.
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?
Flags: needinfo?(m_kato) → needinfo?(maxsong)
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?
Flags: needinfo?(maxsong) → needinfo?(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.
Flags: needinfo?(m_kato)
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.
Flags: needinfo?(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.
Flags: needinfo?(m_kato)
s/Kanaji/Kanji
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.
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?
Flags: needinfo?(maxsong)
ni to jeclark instead.  This is Flash bug that ImmGetContext doesn't call on our process.
Flags: needinfo?(jeclark)
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.
Flags: needinfo?(jeclark)
You need to log in before you can comment on or make changes to this bug.