Henrik Skupin [:whimboo][⌚️UTC+1] Reporter
	Description • 6 years ago

Seen while investigating https://github.com/mozilla/geckodriver/issues/962.

The click on the button does not always happen for the very first click, but only if I attach a separate `onclick` event listener which must include an `alert()` call. If the `alert` is missing the dropdown does not open.

Also the click event target seem to be different then the one we actually clicked on. How can this be possible with the interactability checks?

Also if the first click doesn't succeed the dropdown element gets stale even with no page load happening. Could that be happening due to some React framework handlers?

I find this used test page very hard to reduce given that I cannot save it locally with all the references. React seems to prohibit using a local copy.

Andreas, given that you implemented the click logic, would you mind to have a quick look at it? Maybe you see something more.

	Andreas Tolfsen ❲:ato❳
	Comment 1 • 6 years ago

There is a small misconception in the attached testcase that the
target element will be the <button>’s parent <div> element.  This
means the final assertion on whether the <div> was the target element
is wrong: the target element is the <button> since it is a descendant
element (is contained by) of <div>.

The DOM click event consistently fires on <button>, verified by the
interaction.flushEventLoop promise always resolving on observing
the click event, not on the browsing context (window) getting
discarded/navigated.  This means that the synthesized click event
from the event.js module causes the DOM event to fire, but not for
the dropdown to actually appear.  I didn’t look into this further.

The window.target reference is successfully returned via
WebDriver:ExecuteScript, but calling WebDriver:GetTagName with it
as a reference causes a stale element reference error to be returned.
In element.isStale I verified that Node.isConnected is failing, and
this means the element has gotten detached from its owner document.
This is usually a result of holding on to a reference to a node
that gets removed from the DOM or for the document to change, i.e.
as result of navigation.

Since we can rule out that navigation occurred, it seems more likely
that the element was somehow mutated or re-added.  I checked that
this does not happen with elements that aren’t clicked, e.g. storing
one of the <div>s, clicking, and later returning it and getting its
tag name works fine.

As whimboo points out it is quite hard to figure out exactly what
React is doing with the element when the click fires, and I’m unable
to reproduce Node.isConnected returning false if I set this up in
devtools.  This leads me to suspect that the synthesized click event
isn’t as privileged as we think and that React intercepts and
manipulates it, or that there is something wrong with the the mutable
sandbox used for script execution.