Closed spooning closed 9 years ago
spooning
commented
9 years ago Originally submitted to Google Code by Andreas.EbbertKarroum on 19 May 2010
I agree that some more mouse releated keywords would help. In the meantime, you can use the "Call Selenium Library" with the selenium methods you just mentioned:
http://robotframework-seleniumlibrary.googlecode.com/svn/tags/robotframework-seleniumlibrary-2.3.1/doc/SeleniumLibrary.html#Call%20Selenium%20Api
spooning
commented
9 years ago Originally submitted to Google Code by jerry57 on 27 May 2010
Thanks for the heads up on this, I am using the Call Selenium Library for now and it appears to be working.
spooning
commented
9 years ago Originally submitted to Google Code by spielman... on 5 Oct 2010
I'm starting to implement this. I'll use a local branch for experiments, so that we can still discuss first whether this should be taken into Selenium Library.
The methods to execute the desired commands already exist, so it should be easy to wrap keywords around them. I'd be happy about ideas for acceptance tests because I'm not entirely sure how to assert that things like a mouse-down-event have occurred. I think we can write such tests by handling those events with a small JavaScript in a test HTML resource. I'll try this, but I welcome any additional ideas.
As there has not yet been any discussion about integration into Selenium Library, I'm leaving the target label empty for now.
spooning
commented
9 years ago Originally submitted to Google Code by spielman... on 28 Oct 2010
Implemented:
I think the rest should be done only if there is a real requirement for it, because there are lots of mouse features that Selenium offers. Jerry, what is your opinion? If those five keywords are enough for the moment, I'll close the issue.
spooning
commented
9 years ago Originally submitted to Google Code by @pekkaklarck on 28 Oct 2010
I would prefer Move Mouse or Move Mouse To instead of Mouse Move. Others don't read that well either, but I'm not sure how they could be improved without making the names too long.
An alternative solution would be just having one keyword Move Mouse which would then take the mode as the second argument like | Move Mouse | Over | my_element |. This would limit the number of new keywords, but I'm afraid it would be confusing to use.
Did you Robert already commit the code? If you did, please tell the revision so that it's easy to look/review the code.
spooning
commented
9 years ago Originally submitted to Google Code by spielman... on 28 Oct 2010
Well, just after I pushed, I noticed your comment. Take a look at r5d9f33f532 - the current implementation is pretty simple because I couldn't think of better names either :-)
It wouldn't be a big effort to change those keywords because at the moment, they are rather pure wrappers to the Python Selenium API, without being very intelligent or well-named.
The problem I see with naming for those keywords is this: Selenium doesn't actually move the mouse over and out of the element, it only simulates the event that would usually occur. Thus, the keyword would have to be named "Simulate Mouse Over" or "Pretend To Be Holding Down The Mouse Button On Element". I'd be happy about any ideas for nicer names though.
spooning
commented
9 years ago Originally submitted to Google Code by @pekkaklarck on 29 Oct 2010
I actually like adding Simulate into the keyword names. It's more describing and somehow makes names easier to read. Even Simulate Mouse Move would be pretty OK name, although Simulate Mouse Movement might be even better.
As Robert wrote the code is pretty straightforward and it looks fine. The docs should probably have the standard note about valid locators (id and name in this case) and about looking at introduction section for more details about locating elements.
Our documentation style is using
"""This is the first line of the doc ....
instead of
""" This is the first line of the doc ....
but that's not such a big deal. I'm just a nitpick. =)
spooning
commented
9 years ago Originally submitted to Google Code by spielman... on 29 Oct 2010
Nitpicking is perfectly acceptable, because it's the only way to achieve a consistent codebase. Just because I cannot resist, here's my nitpicking: the reference to the introduction section was already present for the mouse keywords. ;) I've enhanced it with the standard id and name information.
About the mouse move keyword: I'm a little confused by the documentation in selenium.py (which claims to contain generated code) because the docs for mouse_move say "Simulates a user pressing the mouse button (without releasing it yet) on the specified element." - there's something broken there. This is the fault of Selenium itself (e.g. the same text is present in the Selenium RC Java API docs), the question arising is: does mouse_move really do anything mouse-move-related at all? It would be nice to find an answer to this, because if mouse_move doesn't do what it promises, we don't need a keyword for that.
spooning
commented
9 years ago Originally submitted to Google Code by spielman... on 12 Nov 2010
I'm tending to remove mouse_move again, for 2.5 I think that the original request for mouseover, -out, -down and -up should be enough. As I wrote in comment #9, I'm a little unsure about the behaviour of mouse_move and I would like to investigate this in more detail before adding it to the library as a keyword. Any opinions?
spooning
commented
9 years ago Originally submitted to Google Code by @pekkaklarck on 13 Nov 2010
Removing mouse_move is a good idea if you aren't sure how it actually works. It can be added later if needed. When you Robert commit the final changes, please also update the summary of this issue to mention all the new keywords that were added.
spooning
commented
9 years ago Originally submitted to Google Code by spielman... on 13 Nov 2010
This issue was updated by revision ba278d78e3.
I've removed the mouse move keyword because of unclear behaviour of Selenium. The new keywords are:
Acceptance tests have been implemented and are green. =)
spooning
commented
9 years ago Originally submitted to Google Code by @pekkaklarck on 14 Nov 2010
Just noticed we have Mouse Down On Link and Mouse Down On Image keywords in javascript.py. Should these be deprecated?
spooning
commented
9 years ago Originally submitted to Google Code by @yanne on 15 Nov 2010
On the last minute, we decided to remove Simulate from keyword names.
The old keywords Mouse Down on Image and Mouse Down on Link did not have the simulate either.
Most recent changes are in revision a6cded8cb0bf
spooning
commented
9 years ago Originally submitted to Google Code by spielman... on 15 Nov 2010
Cool. Thanks for cleaning up!
These would greatly extend the usability of SeleniumLibrary and RobotFramework for testing systems where menus support only mouse over to bring up submenus.
Additional items that would be helpful are MouseDown, MouseUp and MouseMove also.
Here is the information from Selenium on these: mouseDown
Simulates a user pressing the mouse button (without releasing it yet) on the specified element.
Arguments:
locator
an element locator
mouseDownAt
Simulates a user pressing the mouse button (without releasing it yet) at the specified location.
Arguments:
locator
an element locator
coordString
specifies the x,y position (i.e. - 10,20) of the mouse event relative to the element returned by the locator.
mouseMove
Simulates a user pressing the mouse button (without releasing it yet) on the specified element.
Arguments:
locator
an element locator
mouseMoveAt
Simulates a user pressing the mouse button (without releasing it yet) on the specified element.
Arguments:
locator
an element locator
coordString
specifies the x,y position (i.e. - 10,20) of the mouse event relative to the element returned by the locator.
mouseOut
Simulates a user moving the mouse pointer away from the specified element.
Arguments:
locator
an element locator
mouseOver
Simulates a user hovering a mouse over the specified element.
Arguments:
locator
an element locator
mouseUp
Simulates the event that occurs when the user releases the mouse button (i.e., stops holding the button down) on the specified element.
Arguments:
locator
an element locator
mouseUpAt
Simulates the event that occurs when the user releases the mouse button (i.e., stops holding the button down) at the specified location.
Arguments:
locator
an element locator
coordString
specifies the x,y