950559 - IME composition window should be positioned at bottom-left of windowless plugin rather than top-left of screen

Status: RESOLVED FIXED

(Core :: Widget: Win32, enhancement)

Description

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

Currently, when IME is used on windowless plugin, composition window is positioned at top-left of the screen. However, this may be too far from the focused windowless plugin.

I'd like to suggest that windowless plugin should be positioned at botton-left of the focused windowless plugin.

A major example of windowless plugin having text field is chat system of ustream.

Comment 1

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

Attachment: screenshot of patched build

Comment 2

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

Attachment: part.1 nsContentEventHandler should set plugin's rect to query editor rect event if plugin has focus

When plugin has focus, query editor rect event should return the rect of the focused plugin because we cannot know the actual editor rect in plugin.

Comment 3

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

Attachment: part.2 nsIMM32Handler should set IME releated windows to left-bottom of focused plugin

If focused plugin is clipped by its window, this patch aligns the position of composition window to the window's client rect's edge since composition window must be positioned on client area of window.

You can test the behavior with tryserver build:
https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=9afe578c1663

Comment 4

[Masatoshi Kimura [:emk]]

Comment on attachment 8347896 [details] [diff] [review]
part.2 nsIMM32Handler should set IME releated windows to left-bottom of focused plugin

Indeed this is an improvement.
By the way, IE11 displays the caret just below the text. Do you know how ActiveX Flash Plug-in tell the caret position to IME?

FYI, I've made a test page for higher versions of swf:
http://emk.name/test/swftxt.html

Comment 5

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

Comment on attachment 8347896 [details] [diff] [review]
part.2 nsIMM32Handler should set IME releated windows to left-bottom of focused plugin

> By the way, IE11 displays the caret just below the text. Do you know how
> ActiveX Flash Plug-in tell the caret position to IME?

I guess that the reason is, there is no process boundary. Then, Flash can access the IMC directly.

Comment 6

[Masatoshi Kimura [:emk]]

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #5)
> I guess that the reason is, there is no process boundary. Then, Flash can
> access the IMC directly.

When I open the test page, FlashUtil_ActiveX.exe runs.

Comment 7

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

(In reply to Masatoshi Kimura [:emk] from comment #6)
> (In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #5)
> > I guess that the reason is, there is no process boundary. Then, Flash can
> > access the IMC directly.
> 
> When I open the test page, FlashUtil_ActiveX.exe runs.

Although, I'm not familiar with the plugin architecture with ActiveX, doesn't run a part of plugin in browser process? In other words, must ActiveX plugin run only in other process?

Comment 8

[Masatoshi Kimura [:emk]]

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #7)
> Although, I'm not familiar with the plugin architecture with ActiveX,
> doesn't run a part of plugin in browser process? In other words, must
> ActiveX plugin run only in other process?

An ActiveX control is a COM object. Applications can create a COM object either in-process or out-of-process. It can even create an object across the network by virtue of DCOM technology.

IE11 even implements on-the-spot input with SWF6+. (Maybe using TSF?)

Comment 9

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

Yeah, therefore, I guess that there is "in-process part" for accessing IME context.

Hmm, it's difficult to believe that Flash uses TSF. However, it might be true because they worked with MS for IE11 for Metro.

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #0)
> I'd like to suggest that windowless plugin should be positioned at
> botton-left of the focused windowless plugin.
What if there is no space underneath the plugin? Where will the composition window be?

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8347893 [details] [diff] [review]
part.1 nsContentEventHandler should set plugin's rect to query editor rect event if plugin has focus

But I think this is ok, and the widget level code perhaps needs to handle the case when there is no room for the window.

Comment 12

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

(In reply to Olli Pettay [:smaug] from comment #10)
> (In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #0)
> > I'd like to suggest that windowless plugin should be positioned at
> > botton-left of the focused windowless plugin.
> What if there is no space underneath the plugin? Where will the composition
> window be?

As I said in comment 3, if the plugin rect is clipped, the composition window position is aligned to the edge of window.

(In reply to Olli Pettay [:smaug] from comment #11)
> Comment on attachment 8347893 [details] [diff] [review]
> part.1 nsContentEventHandler should set plugin's rect to query editor rect
> event if plugin has focus
> 
> But I think this is ok, and the widget level code perhaps needs to handle
> the case when there is no room for the window.

Yes. The part.2 patch does it. Thank you.

Comment 13

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/dc369cd5faa8
https://hg.mozilla.org/integration/mozilla-inbound/rev/b643c662a657

Comment 14

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/dc369cd5faa8
https://hg.mozilla.org/mozilla-central/rev/b643c662a657