1386605 - Extend debug logging for seleniumClickElement

Status: RESOLVED WONTFIX

(Remote Protocol :: Marionette, enhancement)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

The command clickElement is most likely one of the most used ones. As such a good debug logging would be very helpful to identify issues with issuing click events on the target. It would also be good to know which element has actually been clicked if that info is available.

There are lots of known test failures right now for which it is not clear where we fail.

Comment 1

[Andreas Tolfsen ❲:ato❳]

(In reply to Henrik Skupin (:whimboo) from comment #0)

> It would also be good to know which element has actually been
> clicked if that info is available.

This information is available if you use the WebDriver
conforming Element Click implementation, cf.
https://searchfox.org/mozilla-central/rev/bbc1c59e460a27b20929b56489e2e55438de81fa/testing/marionette/interaction.js#187-189.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Correct. So until we can enable the webdriver conforming click element implementation I would like to get some more info about failing clicks for seleniumClickElement.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Hm, so in both cases we perfectly raise exceptions in cases when a click would not be possible. But what's actually missing is a part when we can make sure a click has really been issued eg. in `event.synthesizeMouse()`. If the synthesized click event doesn't reach the target, no error will be thrown. It's just silently ignored. 

It doesn't look like that DOMUtils still support a method as what we had in EventUtils which included an expectation that a click must happen.

Andreas, is that something we want to do at all? I mean it's not in the spec, and we wait for all events flushed via `requestAnimationFrame`. But with the current method we would defer the failure to the next command.

Comment 4

[Andreas Tolfsen ❲:ato❳]

(In reply to Henrik Skupin (:whimboo) from comment #3)

> Hm, so in both cases we perfectly raise exceptions in cases when
> a click would not be possible. But what's actually missing is a
> part when we can make sure a click has really been issued eg. in
> `event.synthesizeMouse()`.  If the synthesized click event doesn't
> reach the target, no error will be thrown. It's just silently
> ignored.
> 
> It doesn't look like that DOMUtils still support a method as what
> we had in EventUtils which included an expectation that a click
> must happen.
> 
> Andreas, is that something we want to do at all? I mean it's not
> in the spec[.]

I don’t think “ensure the requested element is hit or return an
error” is something we can define in web platform terms, hence the
element click intercepted check using document.elementsFromPoint.
As I understand it, that check equivalent, no?

> and we wait for all events flushed via
> `requestAnimationFrame`. But with the current method we would
> defer the failure to the next command.

Sorry, I don’t think I understand exactly what you mean.

We flush the event queue to ensure any side-effects caused by the
DOM as a result of the click have time to execute before we return
control to the user.  What does this have to do with “deferring
the failure”?

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to Andreas Tolfsen ‹:ato› from comment #4)
> > and we wait for all events flushed via
> > `requestAnimationFrame`. But with the current method we would
> > defer the failure to the next command.
> 
> Sorry, I don’t think I understand exactly what you mean.
> 
> We flush the event queue to ensure any side-effects caused by the
> DOM as a result of the click have time to execute before we return
> control to the user.  What does this have to do with “deferring
> the failure”?

Sorry for the bad wording. What I meant is that currently it doesn't cause a failure for the call to `clickElement()` but the next executed command. Even `clickElement` returned success, we cannot be sure that the element as wanted has received the click.

Comment 6

[Andreas Tolfsen ❲:ato❳]

Right, if seleniumClickElement doesn’t _actually_ end up hitting
the element but some other coordinates, no error is returned.  I
don’t think we should mess with the Selenium click implementation
unnecessarily, because I don’t think Selenium expects it.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Ok, lets wait then with all the click intermittents until we switched over to the spec compliant method.