Hi devs,
While debugging the failing Selenium tests, most of which are
flickers, I "discovered" a behaviour that I was not aware of. It looks
like when you ask Selenium to click on an element from the page it
does the following:
* locate the element in the DOM
* compute the bounding rectangle (and thus determine if the element is visible)
* scroll the element into view if needed
* move the mouse in the center of the bounding rectangle
* fire a click event with the mouse coordinates
There are two important things to note:
(1) The click event is not bound to the element. The browser behaves
as if the user clicked at that position (x, y) on the page, on
whatever is displayed on top.
(2) The click command doesn't seem to be atomic (i.e. the element
position can change between the moment its bounding rectangle is
computed and the moment the click event is fired).
This allows for the following to happen:
(i) The floating content/edit menu can silently prevent elements to be
clicked (if the page is scrolled and the element is at the top of the
window and the middle of the element is right beneath the floating
menu).
(ii) Clicking on buttons before the page layout is stable can fail
silently. For instance, clicking on Save & View before the WYSIWYG
edit mode is fully loaded can fail silently because the position of
the button is not stable.
Moreover, it seems that the mouse position is "remembered" between
page loads and the browser reacts to it. For instance, if you click on
"Back to edit" in preview mode (and don't move the mouse) the mouse
can end up above the edit menu thus opening it which in turn prevents
you from clicking on the Link menu from the WYSIWYG editor tool bar
(you end up in Object or Class edit mode..).
I'm not sure if this is something introduced in a recent version of
Selenium or if it was triggered when I enabled native events.
Thanks,
Marius