Need automated tests for IME related code

NEW
Assigned to

Status

()

10 years ago
2 years ago

People

(Reporter: masayuki, Assigned: masayuki)

Tracking

(Depends on: 2 bugs, {inputmethod, meta})

Trunk
inputmethod, meta
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

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.
(Assignee)

Updated

10 years ago
Depends on: 460059
Ah, creating the automated tests for nsQueryContentEventHandler may be good thing.
(Assignee)

Updated

10 years ago
Depends on: 489726
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.
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.
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?
(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.
Depends on: 520732
(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.
(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.
Depends on: 528396
Keywords: inputmethod
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.
Depends on: 1322744
You need to log in before you can comment on or make changes to this bug.