W3C home > Mailing lists > Public > public-browser-tools-testing@w3.org > January to March 2017

Re: Intercepting element clicks

From: David Burns <dburns@mozilla.com>
Date: Mon, 16 Jan 2017 19:58:28 +0000
Message-ID: <CAAoW2AEU+6QFbATRK6k10EFxyhoA5v2xfdhBB4FPJYiOG9pTGQ@mail.gmail.com>
To: Simon Stewart <simon.m.stewart@gmail.com>
Cc: public-browser-tools-testing <public-browser-tools-testing@w3.org>
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.


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

> 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
Received on Monday, 16 January 2017 19:59:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:09:55 UTC