New `Mouse Over`, `Mouse Out`, `Mouse Down`, and `Mouse Up` keywords

[GoogleCodeExporter]

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 

Original issue reported on code.google.com by jerry57@gmail.com on 18 May 2010 at 8:13

[GoogleCodeExporter]

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-sel
eniumlibrary-2.3.1/doc/SeleniumLibrary.html#Call%20Selenium%20Api

Original comment by Andreas.EbbertKarroum@gmail.com on 19 May 2010 at 9:15

• Changed state: Accepted

[GoogleCodeExporter]

Thanks for the heads up on this, I am using the Call Selenium Library for now 
and it
appears to be working.

Original comment by jerry57@gmail.com on 27 May 2010 at 4:09

[GoogleCodeExporter]

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.

Original comment by spielman...@googlemail.com on 5 Oct 2010 at 6:42

• Changed state: Started

[GoogleCodeExporter]

Original comment by spielman...@googlemail.com on 24 Oct 2010 at 2:36

• Added labels: Target-2.4.1

[GoogleCodeExporter]

Implemented:

* Mouse Over
* Mouse Out
* Mouse Down
* Mouse Up
* Mouse Move

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.

Original comment by spielman...@googlemail.com on 28 Oct 2010 at 8:55

[GoogleCodeExporter]

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.

Original comment by pekka.klarck on 28 Oct 2010 at 9:37

[GoogleCodeExporter]

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.

Original comment by spielman...@googlemail.com on 28 Oct 2010 at 10:20

[GoogleCodeExporter]

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. =)

Original comment by pekka.klarck on 29 Oct 2010 at 11:52

[GoogleCodeExporter]

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.

Original comment by spielman...@googlemail.com on 29 Oct 2010 at 11:31

[GoogleCodeExporter]

Original comment by janne.t....@gmail.com on 12 Nov 2010 at 7:01

• Added labels: Target-2.5

[GoogleCodeExporter]

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?

Original comment by spielman...@googlemail.com on 12 Nov 2010 at 6:33

[GoogleCodeExporter]

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.

Original comment by pekka.klarck on 13 Nov 2010 at 8:58

[GoogleCodeExporter]

This issue was updated by revision ba278d78e3.

I've removed the mouse move keyword because of unclear behaviour of Selenium. 
The new keywords are:

* Simulate Mouse Over
* Simulate Mouse Out
* Simulate Mouse Down
* Simulate Mouse Up

Acceptance tests have been implemented and are green. =)

Original comment by spielman...@googlemail.com on 13 Nov 2010 at 9:34

• Changed state: Review

[GoogleCodeExporter]

Just noticed we have `Mouse Down On Link` and `Mouse Down On Image` keywords in 
javascript.py. Should these be deprecated?

Original comment by pekka.klarck on 14 Nov 2010 at 9:33

[GoogleCodeExporter]

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

Original comment by janne.t....@gmail.com on 15 Nov 2010 at 2:46

• Changed state: Done

[GoogleCodeExporter]

Cool. Thanks for cleaning up!

Original comment by spielman...@googlemail.com on 15 Nov 2010 at 2:55

[GoogleCodeExporter]

Original comment by pekka.klarck on 16 Nov 2010 at 11:34

• Changed title: Mouse Over, Mouse Out, Mouse Down, and Mouse Up keywords

[GoogleCodeExporter]

Original comment by pekka.klarck on 16 Nov 2010 at 11:38

• Changed title: New Mouse Over, Mouse Out, Mouse Down, and Mouse Up keywords