Due to the continual breakage and unbreakage of Input Methods I have been going mad. We really need some ability to ensure we don't continually regress Input Method behaviour, eg. DRT needs to support IM tests.
Created attachment 15617 [details] Woo, an ability to test input method behaviour!!!!!
Comment on attachment 15617 [details] Woo, an ability to test input method behaviour!!!!! + * ChangeLog: This needn't be in the ChangeLog. + (-[InputMethodController setIMEFunction:]): I'd call this setIMEventHandler. Generally, it would be nice not to say "IME" in Mac code. Index: DumpRenderTree/InputMethodController.h Would it make sense to implement this within TextInputContoller, which already has NSTextInput methods? We seem to get quite a bit of code duplication. + WebScriptObject *imeFunction; + WebHTMLView *view; Coding style: please prefix Objective-C instance variables with "_". + WebScriptObject *modifiers = [imeFunction evaluateWebScript:@"new Array();"]; I think you can work with an NSArray, and converted to WebScriptObject later - the current code doesn't look nice. Mark had more to say about that on IRC. r- mostly because of code duplication.
Created attachment 15622 [details] Mark 2, this time without repeating a lot of code i wish i had realised was there Here we go again
Alas I can't use NSDictionary as it doesn't get mapped into a usable JS object, so the Event structure is still a damnable WebScriptObject. I'm thinking the best approach the the IMs is to build up <IMengine.js> for whatever engines we have bugs against, and as time goes by incorporate more of each IMs behaviour into the scripts.
Comment on attachment 15622 [details] Mark 2, this time without repeating a lot of code i wish i had realised was there Seems like a great start for testing this sort of thing. My one suggestion would be to have more of this done with an eye toward future platform-independence, for example leaving the "NS" out of the string constants for our JavaScript API. r=me
A minor comment: earlier NSTextInput tests are in editing/input, I think the test from this patch can go there, too.
Landed in r r24517 Without Alexeys test location, as his comment came though just as i committed, is it really worth moving them? :-/
Well, there doesn't seem to be any reason to have two directories for these tests :(
I have a reason: I can just add the entire inputmethods directory to the windows skiplist In future we may need to have intputmethods/mac and inputmethods/win in which case keeping them isolated will be beneficial
Maybe editing/input/mac will do then?
I would prefer to keep them completely seperate from the other input methods ... how about events/input (as you say) and events/input/inputengines/<engine, eg. kotoeri>/<platform> If we could come up with someway of getting the right engine for the platform it would be great and then just have a generic test with a non-generic engine implementation...
(In reply to comment #11) > events/input (as you say) More precisely, editing/input > and events/input/inputengines/<engine, eg. kotoeri>/<platform> I'm not quite convinced that most of these tests will be engine-based, but I'm OK with trying such a structure.
Well i'm assuming that we'll be making tests to ensure we don't regress various IM engines, so engines would contain (for example) kotoeri.js, and hangul.js, because otherwise whenever you want to test something you putting quite a bit of effort just to ensure the rest of the IM behaviour is correct. For now editing/input/mac would do, but i'm trying to think of the future
Created attachment 15627 [details] Move current IM tests to editing/input/mac, update skip lists
Moved tests in r24522