1. Click on a menupopup with mozmill = Actual = popup doesn't close = Expected = Popup should close. = Test = var setupModule = function(module) { controller = mozmill.getPreferencesController(); } var testRecorded = function () { controller.click(new elementslib.Lookup(controller.window.document, '/id("BrowserPreferences")/anon({"orient":"vertical"})/anon({"anonid":"selector"})/{"pane":"paneMain","label":"General"}')); controller.click(new elementslib.ID(controller.window.document, "browserStartupPage")); controller.click(new elementslib.XPath(controller.window.document, "/*[name('prefwindow' and namespace-uri('http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul']/*[name('prefpane' and namespace-uri('http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul'][1]/*[name('groupbox' and namespace-uri('http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul'][1]/*[name('hbox' and namespace-uri('http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul'][1]/*[name('menulist' and namespace-uri('http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul'][1]/*[name('menupopup' and namespace-uri('http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul'][1]/*[name('menuitem' and namespace-uri('http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul'][2]")); } = Cause and Resolution = This is caused by the mouseup event never making it to the event nsXULPopupManager event subsystem. We can fix this in mozmill by adding a sleep(0) to the end of controller.click() which is what we've done.

Pushed r532, r=mikeal, flagging with mozmill-1.2.1 so that we can remember to pick this up for that release.

Isn't that a problem in EventUtils.js? I wonder how browser chrome tests are handling this specific situation. And it will not only affect the click code. Nearly each event (right click, double click, mouse down, keypress, ...) triggers this behavior. See also bug 497696 and bug 497685 for menus which behave the same way in Mozmill. IMO this needs a more general fix. But I even don't know if that's really Mozmill specific. I believe Neil will be able to give us insights here. Reopening the bug and adding dependencies.

mochitests are asynchronous and do lots of validation in callbacks. Since they don't lock up the main thread of execution like mozmill does this isn't an issue.

That means we should move the sleep call to our EventUtils.js or events.js?

Ideally, we could do a simpler call that made sure the main thread event loop gets called after every controller action. We've been talking for a while about architecting a wrapper around all the controller functions to do common pre and post actions.

If we really have similar issues with other controller actions those could be the issue of several dependencies I have. I'll try to use sleep manually in those tests to check if that helps. Otherwise great idea!

Updating summary to better reflect what has to be done here.

(In reply to comment #5) > We've been talking for a while about architecting a wrapper around all the > controller functions to do common pre and post actions. As what we have seen on bug 506275 calling sleep(0) is enough in such cases. Mikeal, any update how we can do that?

So, it would be as simple as iterating over all the controller methods we want to do this to and replacing them with a wrapper function. This has the side effect of making all the functions anonymous and you guys seem to hate debugging those with your fancy debuggers :)

Logging here one more case. controller.select calls sleep(0) only after the first click for a menulist element and not after the second one. This works fine in most cases, but not in the case where the select call should trigger a modal dialog. Then modal dialog never appears and instead the function following start call for modal dialog API is called and modal dialog actions never run. If sleep(0) is called after select then modal dialog opens up normally.

Mozmill will reach its end of life soon. We are currently working on getting all the tests for Firefox ported to Marionette. For status updates please see bug 1080766.