Closed Bug 497685 Opened 15 years ago Closed 10 years ago

Mozmill cannot automate standard windows/linux menu keystroke behavior

Categories

(Testing Graveyard :: Mozmill, defect)

x86
Windows Vista
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: cmtalbert, Unassigned)

References

Details

Attempt to automate the keystroke that launches the preference dialog. This involves ALT+T,o on windows and ALT+E,n on Linux. You'd think that for the windows case, you'd use a test like this: controller = mozmill.getBrowserController(); controller.keypress(new elementslib.ID(controller.window.document, "bookmarksBarContent"), "t", {altKey: true}); controller.keypress(new elementslib.ID(controller.window.document, "menu_ToolsPopup"), "o", {}); But even though that second keypress is directed at exactly the element that is created when the menu pops up, the keypress never actually happens. The keypress fires, but the event simply falls on the floor and nothing happens.
As we said on another bug we have to skip shortcuts for now. So your mentioned problem should not block us from adding the API for the preferences dialog. For now we are using the menu API to open the preferences dialog or calling getPreferencesController. The latter one should be the default way while we only need one test for the menu and shortcut. But for this bug we have to check why that doesn't work.
This only happens for menus. It works on other places. Neil, on which elements we have to fire the second key event to get the menu item selected?
Summary: Mozmill cannot automate standard windows/linux keystroke behavior → Mozmill cannot automate standard windows/linux menu keystroke behavior
Key event synthesis doesn't require an element to fire at. It will get redirected to whatever is focused or the right listeners automatically. The issue here is that you're not waiting for the menu to open until attempting to activate a menuitem from it. You should respond to the popupshown event.
Thanks Neil. That's the solution. Do we have to interpret the popupshown event or can we also use a wait function which checks the visibility of the element we wanna work on? Lets say the menu_ToolsPopup?
Neil, are most of the controls working asynchronously? What about context menus, menulists and so on. Do we have to obey the event in all that cases or do we have to differentiate between two types of controls. If it will be the latter one what is the difference?
Waiting for the popupshown event will always work, whereas any other method may or may not work, and isn't guaranteed to work or not work in the future.
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.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
Product: Testing → Testing Graveyard
You need to log in before you can comment on or make changes to this bug.