Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090413 Shiretoko/3.5b4pre ID:20090413031313 While reviewing the tests from the last Mozmill testday, I have noticed that controller.keypress doesn't work for certain shortcuts we have, e.g. Cmd+J to open the download manager. On Windows those shortcuts work with the Ctrl parameter set to true. See the attached test for the OS X issue.

Shortcut testing was pushed to future. Right now I don't see a situation where we really need this working. Most times we can use menu entries or click the element directly to set the focus. P3 should be the right choice I believe.

agreed with c#1. We will tackle keyboard shortcuts as a separate test suite in the future.

Spent some time debugging this, the correct event is getting dispatched however event metakey j on mac doesn't seem to be doing the trick. I am wondering if this has something to do with the seperating in mac menu's.

Adam, compare it how it is done for the browser-chrome test: http://mxr.mozilla.org/mozilla-central/source/toolkit/components/downloads/test/browser/browser_bug414214.js http://mxr.mozilla.org/mozilla-central/source/testing/mochitest/tests/SimpleTest/EventUtils.js#298 Probably we mess-up with the keycode.

Looks like what we need to do is detect if the keyboard event is being fired on a window, and if it is we can use synthesizekey right out of the box. I'll work on this today.

Committed revision 456. Example test: var mozmill = {}; Components.utils.import('resource://mozmill/modules/mozmill.js', mozmill); var elementslib = {}; Components.utils.import('resource://mozmill/modules/elementslib.js', elementslib); var setupModule = function(module) { controller = mozmill.getBrowserController(); } var testRecorded = function () { controller.keypress(new elementslib.ID(controller.window.document, "main-window"),106,false,false,false,true); }

Woops, please check this with existing keyevent tests, marking fixed.

Adam, now it works on OS X but fails on Windows. Use the recorder to create a test and open the download manager. You will get a keycode of 119 instead of 106 which is bogus. The keycode itself should not change when pressing different accelerator keys. So what I can see is that you have added a special case when sending a keypress event on a window. We cannot rely on this function at all? Mikeal said on the other bug that we send a different kind of events as the mochitests. Can you explain it too me? For those you can also use "W" as keycode which is much more discoverable.

controller.keypress(new elementslib.ID(controller.window.document, "main-window"),106,false,false,false,true); controller.keypress(new elementslib.ID(controller.window.document, "main-window"),106,true,false,false,false); Those are what I record in mac and windows respectively and they both work correctly. I can't repro 119, but 119 is the 'w' character, so I am guessing that you are closing the window with meta w and that is getting picked up by the recorder. We are currently using synthesizekey from EventUtils to fire the event against the window because it uses utils.sendKeyEvent and I don't see anyway to fire that against an element since utils.sendKeyEvent appears to be designed to fire against a window and doesn't provide any other facilities that im aware of. The ability to use a string instead of the charCode is just a design decision, it could easily be changed if we felt it was a priority. The only bug that I can actually seem to find is that firing the key events fail both ways in linux (which needs to be logged)

Adam, that's true. Somehow the first event wasn't fetched. Now it is fine. But why we have to differentiate between the metakeys. It would be really handy to have something like we have in Mochitest: var key = navigator.platform.match("Linux") ? "y" : "j"; EventUtils.synthesizeKey(key, {metaKey: true}, window.opener); This seems to work on all platforms while we have to differentiate between cmd and ctrl. Even using the character itself is much more self-explanatory and makes it much easier to write tests without having to know the char code itself.

Adam, those changes have been caused a regression on trunk. Right now any keypress event in the e.g urlbar isn't recognized anymore. Nothing is propagated to the widget anymore. See the attached test.

The only way that new code should even be getting called is if the element you pass is a window, else it should still be calling the old event firing code. Can you get synthesize key to fire these correctly? If so I can just move that old event firing code over to that.

Adam, see my latest test attached to this bug. As you can see I don't operate on the window but the urlbar itself. You are on OS X, right? Just try out this test and you will see it. Right now i don't know what I could/should do here.

Need to get this fixed asap. Marking blocker.

Ok, together with Adam we were able to figure out the remaining keypress issue. It hasn't been regressed by the work on this bug. Instead it was introduced with r424 which is bug 483172. Lets close this one and file a new bug for the regression.

Verified fixed with my test on bug 493226.

The newly filed bug is bug 494071.