573280 - [OOPP] ibus input method can not work correctly in flash plugin

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect)

Description

[Peng Huang]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/534.1 (KHTML, like Gecko) Chrome/6.0.437.3 Safari/534.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; zh-CN; rv:1.9.2.4) Gecko/20100611 Firefox/3.6.4Mozilla/5.0 (X11; U; Linux i686; zh-CN; rv:1.9.2.4) Gecko/20100611 Firefox/3.6.4

Some input methods can not work correctly in flash plugin. I think the problem is because of the new plugins-container. It does not set client window via gtk_im_context_set_client_window API, and some input method can not work without client window. Please check it.

Reproducible: Always

Steps to Reproduce:
1. Install latest ibus from https://launchpad.net/~shawn-p-huang/+archive/ppa
2. ibus-darmon -rvx            # to start ibus input method
3. GTK_IM_MODULE=ibus firefox  # start firefox 3.6.4
4. Find a page with flash
5. Typing someting in flash
Actual Results:  
can not type anything

Comment 1

[Benjamin Smedberg]

You confirmed that the input method does work if you run in-process (setting the dom.ipc prefs to false?)

Comment 2

[Peng Huang]

No. It still has this problem. Actually the I developed the ibus gtkimcontext, and found firefox does not set client window.

Comment 3

[Karl Tomlinson (:karlt back Feb 10)]

When I load http://www.developingwebs.net/flash/inputdyn.php with
GTK_IM_MODULE=xim in the environment I see libflashplayer version 10.0.45.2 in
the plugin-container calling gtk_im_context_set_client_window an number of
times in response to an early NPP_SetWindow call.  I see this both with Firefox 3.6.3 and with a trunk build.

With older flashplayer versions (or an older version of the web site) I used
to see another gtk_im_context_set_client_window call when clicking in the
"Type Here" box.  (I no longer see that.)

Comment 4

[Karl Tomlinson (:karlt back Feb 10)]

(In reply to comment #0)
> I think the problem is because of the new plugins-container.

Can you explain why you think that, please?

Comment 5

[zsl1005]

(In reply to comment #3)
> When I load http://www.developingwebs.net/flash/inputdyn.php with
> GTK_IM_MODULE=xim in the environment I see libflashplayer version 10.0.45.2 in
> the plugin-container calling gtk_im_context_set_client_window an number of
> times in response to an early NPP_SetWindow call.  I see this both with Firefox
> 3.6.3 and with a trunk build.
> 
> With older flashplayer versions (or an older version of the web site) I used
> to see another gtk_im_context_set_client_window call when clicking in the
> "Type Here" box.  (I no longer see that.)

The xim module is poor, it cannot support many useful features when inputting CJK characters, and the ibus module was supported very well in firefox 3.6.3 and older version with flash plugin version 10.1, by the way, flash plugin version 10.0 cannot support ibus module and many CJK users filed this bug to adobe, and finally the bug is solved in flash 10.1, but it is sad that the module cannot work correctly again in firefox newest version.

Comment 6

[Peng Huang]

(In reply to comment #4)
> (In reply to comment #0)
> > I think the problem is because of the new plugins-container.
> 
> Can you explain why you think that, please?

I mean in the firefox 3.6.4, the flush plugin is running in as separated process with plugin-container, I guess the plugin-container may has some problem.
And firefox 3.6.3 does not have this problem.

Comment 7

[Benjamin Smedberg]

Comment 6 and comment 2 seem to be at odds: if you set the dom.ipc prefs to false, there won't be any plugin-container process, and Firefox 3.6.4 should behave almost exactly like Firefox 3.6.3.

Comment 8

[zsl1005]

(In reply to comment #7)
> Comment 6 and comment 2 seem to be at odds: if you set the dom.ipc prefs to
> false, there won't be any plugin-container process, and Firefox 3.6.4 should
> behave almost exactly like Firefox 3.6.3.

Yes, I just try to disable the plugin-container, everything worked very well, nothing wrong. maybe the reporter in comment 2 made something wrong

Comment 9

[zsl1005]

By the way, the value of pref "dom.ipc.plugins.enabled" is "false" by default, but I don't know the reason that the plugin-container was still enabled. "dom.ipc.plugins.enabled.libflashplayer.so" is "true" by default, I set this value to "false", everything is OK. So I can confirm this bug caused by plugin-container.

Comment 10

[Karl Tomlinson (:karlt back Feb 10)]

(In reply to comment #5)
>  the ibus module was supported very well in firefox 3.6.3
> and older version with flash plugin version 10.1, by the way, flash plugin
> version 10.0 cannot support ibus module and many CJK users filed this bug to
> adobe, and finally the bug is solved in flash 10.1, but it is sad that the
> module cannot work correctly again in firefox newest version.

Can you tell us what Adobe changed in 10.1 to support ibus?
10.0 was calling gtk_im_context_set_client_window, but apparently not in a way that was useful to ibus?

Comment 11

[Peng Huang]

I don't know what change in flash plug 10.1.
But I can tell you why ibus need the client window.

1) In gtk_im_context_set_cursor_location, the cursor location is relative to client window, without the correct client window, ibus can not show candidates lookup table in correct position.

2) In the latest ibus, we changed to use async mode to handle key events (It will not block application anymore). It means gtk_im_context_filter_keypress will always return TRUE immediately (the key event is consumed by im context, and sent to ibus server). If the key event is not handled by the server, the im context will use gdk_event_put to send the key event back to client window. Without the client window, the key events will be lost for every.

BTW, I tried a workaround in ibus. It uses event->window to call _set_client_window. It could fix this problem. But I think it is not a good solution.

Comment 13

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

karlt:

I think that we can close this bug and this wasn't really our bug because Flash Player 10.1 doesn't have this bug.

I think that the comment 11 is another issue, it should be separated from this bug.

Comment 14

[Karl Tomlinson (:karlt back Feb 10)]

Thanks, Masayuki.
Comment 5 said that ibus wasn't working with Flash 10.1, but, if it is working now, then perhaps Adobe changed something in an update, so we can mark this WFM.