460056 - [meta] Need automated tests for IME related code

Status: NEW

(Core :: DOM: UI Events & Focus Handling, task)

Description

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

Now, we don't have IME automated testing. But it's needed.

I think that we should create following IME tests:

1. Focused content IME state checking
  Now, we manage the IME state (opened/closed/enabled/disabled) when a content is focused. We need to test whether the IME state managing is broken.

2. Synthesize native IME events like native key event testing
  We have native key event testing. We should create similar test for IME. I think that some complex behavior may not be able to test, but we can test many simple IME behaviors.

3. Candidate window position test
  For bug 447945, we need candidate window position test. However, I don't have good idea for this test.

I'll file bugs for each tests with patch. This bug is meta bug for them.

Comment 1

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

Ah, creating the automated tests for nsQueryContentEventHandler may be good thing.

Comment 2

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

I'm still thinking about this. I think that IMM32 test may be possible following structure:

We create a scriptable interface nsIMM32Listener. It's implemented in the automated test (by javascript). And we should create an IME APIs wrapper class nsIMM32API which hides the native APIs from nsWindow and nsIMM32Handler. And the nsIMM32Listener methods are called by nsIMM32API only during testing.

And also we should create new methods to nsIDOMWindowUtils which are sendNativeWindowsMessage and postNativeWindowMessage. Then, we can write the IMM32 automated testing by javascript.

So, I'm thinking the test interfaces, and implementation isn't XP model. If we can combine the all interfaces in the future, we should do it. But I should create the tests fast as far as possible.

Comment 3

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

And if possible, we should reimplement the TSF automated testing on javascript layer because the current test is too hard for creating another test case.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

What other applications, like Safari or Chromium, do for automated IME testing?

Can we implement an actual IME for testing and communicate with it from the browser?

Comment 5

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

(In reply to comment #4)
> What other applications, like Safari or Chromium, do for automated IME testing?

I'm not sure.

> Can we implement an actual IME for testing and communicate with it from the
> browser?

I think that it's impossible at least on Windows because we cannot control IME from applications. IME is created by DDK, not SDK. And also the IME is needed to be installed to the test machine. It's not realistic. Additionally, some IMEs have characteristic behavior (e.g., characteristic message pattern), if we implement the pseudo IME in javascript, we can test it easily.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to comment #4)
> What other applications, like Safari or Chromium, do for automated IME testing?

We should find out.

But your approach may be the best.

Comment 7

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

(In reply to comment #6)
> (In reply to comment #4)
> > What other applications, like Safari or Chromium, do for automated IME testing?
> 
> We should find out.

Looks like WebKit doesn't test IME in the tree because ImmGetCompsitionString isn't wrapped. So, WebKit always gets the actual composition string of the current IME.

Comment 8

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

Now, we have a lot of regression reports when we fix some bugs around native IME event handlers and which really break my plan to fix other bugs. So, it is the time to implement automated test framework (I think we should use mochitest).

TSF, Cocoa and GTK are important. I'm not sure about IMM and Android (especially, I'm not familiar with Android's IME API).

My plan is, each test emulates the behavior of specific situation. For doing that, JS should be able to kick native IME event handler with XPCOM interface and JS should be able to listen to feedback for IME from us.

Currently, we have nsITextInputProcessor interface which allows to emulate key inputs and composition events. I think that new interface should be able to attach via this interface. Then, nsITextInputProcessor shouldn't work as is until detaching the interface from native IME handler. So, I think that the JS test needs to be written in chrome process but it can test e10s behavior when focus is in a remote process, although, I'm not sure if it's necessary.

Comment 9

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

Resetting assignee which I don't work on in this several months.