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.
Ah, creating the automated tests for nsQueryContentEventHandler may be good thing.
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? 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.
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.
You need to log in before you can comment on or make changes to this bug.