Re: Spec Feedback - CLICK

Jim's done a good job at addressing most of this, but I'll try and add some
details inline.

On Tue, Oct 29, 2013 at 5:51 PM, John Jansen <John.Jansen@microsoft.com>wrote:

>  The Spec Says: ****
>
> “Click in the middle of the WebElement instance. The middle of the element
> is defined as the middle of the box returned by calling
> getBoundingClientRect on the underlying DOM Element” [1]****
>
> There seems to be some ambiguity about where the cursor may go after the
> click happens. For example, clicking on a textbox in Firefox without
> width/height defined puts click at the beginning. Chrome put it in the
> center of the text box. It is not clear what we should expect to happen in
> these cases.
>

I take it you're talking about clicking on either INPUTs of type "text" or
"password" or TEXTAREAs? Chrome would appear to be behaving according to my
expectation from the spec here.


> ****
>
> Additionally, it is possible for the ‘middle’ of an element to be
> obscured, but the clickable dimensions of that div to be clickable. In that
> case, an end user would not click on the middle, but rather in the top left
> area of the element.
>

Covered by Jim.


> ****
>
> Has there been discussion about passing parameters to the click method
> that would move the click some number of pixels up and left or down and
> right of the center of the clientBoundingRect?
>

This is what the advanced user interactions APIs would allow (in the OSS
selenium project, these can be found in the "Actions" class[1]) These, in
turn, are based on the (as yet missing) 14.2.x sections.

The short story is that the methods on WebElement are designed to support
the common case. In particular, in most of the tests I've seen written, the
elements to be interacted with are unobscured and easy to click. The main
exception to this is the "A" tag, which seems to have a habit of spanning
line breaks, which explains the first bullet point in 14.3.1.1.


> ****
>
> Finally, according to the specification click “MUST use either the mouse
> or touch mechanisms for emulating the user input”. Since the Mouse (14.2.1)
> and Touch (14.2.3) sections of the spec have yet to be fleshed out, this is
> a bit confusing.
>

Yeah. That's not a particularly helpful thing to have in the spec right
now. Fixing that before the end of TPAC is one of my goals.


> The wording here is vague on whether or not the click command should cause
> other events to fire (such as OnMouseOver or OnLeftMouseDown).
>

The effect should be as if the user had dragged the mouse from the previous
location used to the current location of the element. On a touch device,
that probably means that only those events that would have fired if the
user were to prod the screen would fire. On a desktop device, there would
likely be far more mouse move (and related) events firing.

Does that help?

Simon


> ****
>
> [1]
> https://dvcs.w3.org/hg/webdriver/raw-file/default/webdriver-spec.html#clicking
> ****
>
> ** **
>

[1]
http://selenium.googlecode.com/git/docs/api/dotnet/html/AllMembers_T_OpenQA_Selenium_Interactions_Actions.htm

Received on Thursday, 31 October 2013 19:02:21 UTC