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