Re: Intercepting element clicks

If we can get it landed, that'd be great. Perhaps someone from the chrome
team can pick this up? They have working code already…. Presumably this is
hooking into the hit testing somehow.

Simon

On Mon, Jan 16, 2017 at 7:58 PM, David Burns <dburns@mozilla.com> wrote:

> 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
>>
>
>