On Fri, Nov 23, 2012 at 11:17 AM, Vincent Massol <[email protected]> wrote: > 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)? Both Selenium 1 and 2, since now Selenium 1 tests run also on WebDriver. > > 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 I enabled native events only on FF because Selenium/WebDriver documentation says "It is disabled by default for Firefox on Linux". They don't mention other browsers. > 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/ Yet they say "However, native events work quite well otherwise and are essential for some of the new actions of the Advanced User Interaction" in http://code.google.com/p/selenium/wiki/TipsAndTricks#Enabling_features_that_are_disabled_by_default_in_Firefox . Note that I don't think the "new" behaviour of Selenium is wrong. It replicates very well the user behaviour. The scenarios I listed above (floating menu, unstable layout, remembered mouse position) happen for real users so I'm for keeping this behaviour. The intent of my mail was to make the devs aware of this behaviour. > > 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... I didn't find any other solution. Note that I didn't discover any problems with native events so far. Thanks, Marius > > Thanks > -Vincent > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
