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
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:09:55 UTC