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)
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.
Comment 1•15 years ago
|
||
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.
Comment 2•15 years ago
|
||
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
Comment 3•15 years ago
|
||
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.
Comment 4•15 years ago
|
||
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?
Comment 5•15 years ago
|
||
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?
Comment 6•15 years ago
|
||
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.
Comment 7•10 years ago
|
||
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
Assignee | ||
Updated•8 years ago
|
Product: Testing → Testing Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•