Hi Marius, On Nov 23, 2012, at 2:04 AM, Marius Dumitru Florea <[email protected]> wrote:
> 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. Nice detective work! Indeed, this is worrying… Are you talking about Selenium1 tests working in Selenium2 (ie our -selenium test module) or Selenium2 tests (ie our -ui test module)? I had missed the fact that you enabled native events (XWIKI-8454). BTW I see that you enabled them for FF only. Does it mean our functional tests will fail on other browsers? Also do they work on all OSes? It's a feature that's been quite unstable in the past and even recently it didn't always work (see http://code.google.com/p/selenium/issues/detail?id=4564 for example). Apparently they don't work on OSX: http://www.seleniumwebdriver.com/google-selenium-webdriver/firefox-native-events-on-os-x-not-working/ Maybe we should try to find a different way to make the WYSIWYG editor test pass without native events? I haven't researched the topic so I don't know what's possible to do but it seems like native events are going to cause us lots of troubles... Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
