I'm sorry I have very little time to look into these things currently. If you make changes to the Simulator user_extensions.js, just keep in mind that other projects are using it too, so don't break existing code. This also means don't just change the signature of existing methods (e.g. clickElementQx), but rather add functionality if necessary.
Furthermore, user_extensions.js should have as little knowledge as possible about how particular widgets are implemented in qooxdoo. This concerns the ComboBox being built on the Table, which can change anytime (as you know ;). I'd rather prefer a more "semantic" abstraction in the user extensions, and work-arounds in the client code. I don't think it is a good idea to click by coordinates when there is a chance to click on identifiable elements anyway. It should boil down to intelligent locators, not coordinates. I'm still wondering why the exact same thing is working in the (rather crude ) test_showcase.js Simulator script ...?! Thomas >> Looking at the DOM it appears that the menu is implemented by a >> table - I can see class qooxoo-table-cell for the div which contains >> the text in the drop-down list. >> >> Perhaps there is a problem with tables and Selenium - see the >> earlier code in test_showcase.js: >> > > In an earlier thread I found reference to > http://qooxdoo.org/documentation/contrib/simulator/qooxdoo-tests-with-sele > nium#clicking_in_tables > > However, I'm using qxClickAt but it's still not working. > > Having done some tracing I've found that the click is getting through, > but the coordinates are outside the pane clipper position. If I click the > first element in the pane, the X coordinate is 251 in my test case but > the clipper starts at 252 (this is in > qx.ui.table.pane.Scroller._getRowForPagePos). Therefore in > qx.ui.table.pane.Scroller._onmousedownPane the "col" is null and no > selection takes place. > > The raw Selenium mouse click routines have the option of passing through > X,Y coordinates. When I use mouseDownAt and pass through 10,10 then the > click works OK. Therefore that is a workaround. > > I note from the qooxdoo Selenium user-extension.js on line 428: > > * TODO: implement it like doFooAt, where additional coordinates will be > added to the element-coords > > Given that you have the eventParams having a large number of options, so > we can't simply pass an X,Y string, I suggest that we extend the > eventParams to have a offsetClientX and offsetClientY value. > > To implement this it would probably be best to have clickElementQx take > an instance of MouseEventParameters rather than the string, so > doQxClickAt can manipulate the coordinates. > > Therefore with this proposed change you could do qxClickAt with params > offsetClientX=10,offsetClientY=10 and it would work OK. > > That would be the second workaround and a useful facility anyway. However, > the main bug is that the start coordinates for the row div are outside > the pane clipper. > > Hugh > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
