Re: Intercepting element clicks

The last one.

Looking at the current prose in Element Click, adding the necessary prose
shouldn't be that difficult. I am happy to take that on.

David

On 16 January 2017 at 14:12, Simon Stewart <simon.m.stewart@gmail.com>
wrote:

> Hi,
>
> The chromedriver, at least, will notify users if they attempt to click on
> an element that isn't actually clickable (eg. because it's covered by
> another) There's an open PR (#299
> <https://github.com/w3c/webdriver/pull/299>) that adds a new "element
> intercepting click" for this, but there's some discussion on that diff
> concerning how this should be implemented.
>
> Rather than leaving the PR languishing in purgatory, we should have a
> discussion here. The choices that I see are:
>
> * Ignore this case, and leave it unspecified.
>
> * Optionally allow drivers to raise an "invalid element state" error if
> the user would not actually be able to click on the element (which may make
> testing for clickjacking impossible since we don't have any language to say
> whether or not an element would be user visible any more)
>
> * Add a new error message, and work out the spec-ese to make this happen.
>
> I'm assuming that this only applies to "Element Click", since the advanced
> user interactions are working on coordinates rather than elements, and so
> should be figuring out the element which should receive events.
>
> If we had the time, the last option feels like the best, with users being
> forced to use the Action commands to test clickjacking. Thoughts?
>
> Simon
>