Re: [xwiki-devs] A note on Selenium behaviour

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.