This page contains tutorials for the qxh= locator, qxClick and qxClickAt action of the user extension.

The normal Selenium click command doesn’t send all the events required by qooxdoo. Therefore qxClick and qxClickAt are provided for qooxdoo mouse actions.

Both commands fire focus, mouseover, mousedown, mouseup and then click.

qxClickAt includes the X and Y coordinates of the located element in the mouse events, which is essential for clicking in qooxdoo tables as the coordinates are used to calculate the selected row and column.

In addition, various parameters can be added for the click including:

• button: the mouse-button to be pressed
  • possible values: left, right, middle
  • default value: left
• ctrlKey, shiftKey, altKey, metaKey: additional modifier keys being pressed during click
  • possible values: true, false
  • default value: false
• clientX and clientY: client coordinates where the click is done
  • possible values: any positive integer
  • default value for qxClick: 0
  • default value for qxClickAt: coordinates of located element
• screenX and screenY: screen coordinates where the click is done
  • possible values: any positive integer
  • default value: 0
• bubbles: whether the event bubbles or not
  • possible values: true, false
  • default value: true
• cancelable: whether the event is cancelable or not
  • possible values: true, false
  • default value: true

An example:

qxClick  <any locator>  button=right, shiftKey=true  

The qooxdoo user extension to Selenium adds a new locator, which has the qxh= prefix in locator strings. The sole purpose of this locator is to make it easy (or at least feasible) to locate elements in a qooxdoo application through relationships between Javascript objects in general, and qooxdoo objects in particular. The aim is to leverage relations established in the application code through various means. Here are a few examples:

this.mytoolbar = tb;
layout.addToDocument();
boxlayout.add(new qx.ui.basic.Label("My top box"));
buttonview.getBar().add(button1);

This means, qxh takes advantage of objects linked through Javascript properties (as in this.mytoolbar, which is a common idiom in qooxdoo applications) and objects you would get through getChildren(), “_getChildren()” or getItems() (for Tree widgets) method calls. In the remainder of this document, the term child refers to all of those objects, independent of how they were obtained. This broadens the set of objects that are in some way linked to the current object. Since this locator traverses a hierarchy of objects, it’s name is “qxh” (”h” for hierarchical).

In order to achieve this, qxh’s syntax is very similar to XPath locators, but also differs in significant ways.

A qxh locator is a sequence of one or more location steps, separated by /. No leading or trailing / is allowed. All searches are anchored to the root object (which is either the Application object or the ClientDocument, see further down). During the search each location step selects an object which will be used as the root for the rest of the search. The following possibilities exist to specify a location step:

• <string> A simple string that cannot be resolved otherwise is taken to be the literal identifier of a Javascript property of the current object. So a locator step of mytoolbar will signify a Javascript property named mytoolbar on the current object.

  qxh=mytoolbar
  

• qx. ... A string starting with qx. is taken to be a qooxdoo classname like qx.ui.basic.Label. It signifies a child which is an instance of the given class.

  qxh=qx.ui.basic.Label
  

• child[N] Signifies the Nth child of the object returned by the previous step.

  qxh=child[3]
  

• [@attrib{=value}] Selects a child that has a property attrib which has a value of value. The specification of a value is optional. “Property” here covers both qooxdoo as well as generic Javascript properties.

  qxh=[@label="My Label"]
  

  As for the values, only string compares are possible, but you can specify a RegExp as value as the comparisons will be RegExp matches.

  qxh=[@label=".* Lab.*l"]
  

  In the special case of [@attrib] (no value specified) the current object (not its children) is searched for a property of that name which has to contain an object reference as its value; this will be the result of the current step.

  qxh=[@page]
  

• * The special token “*” is a wildcard operator. It covers the semantics of XPath’s // and descendant-or-self constructs. The wildcard can span zero to multiple levels of the object hierarchy. This saves you from always specifying absolute locators, e.g.

  qxh=*/[@label="My Button"]
  

  This will search from the first level below the search root recursively for an object with a label property that matches the string “My Button”. As you might expect, these recursive searches take more time than other searches, so it is good advice to be as specific in your locator as possible. To that end, you can use mutliple wildcards in the same locator, like

  qxh=*/[@label="Section 3"]/[@page]/*/[@label="First Button"]
  

  This will search recursively from the root for an object with label “Section 3” and then, assuming it is a ButtonView which has a page property, navigate to the corresponding page, where it again searches recursively for an item with label “First Button”. This is much more effective than searching the whole object space with “*/[@label=”First Button”]”.

• app: Three special operators at the beginning of a locator specify which object space you want to search. app: signifies the object space down from qx.core.Init.getInstance().getApplication(), inline: signifies the object space down from the root widget of a “qooxdoo” isle in an inline application (see the how-to page for details), doc: (or anything else for that matter, including nothing) signifies the object space down from qx.ui.core.ClientDocument.getInstance(). Exp.:

  qxh=app:*/mytoolbar
  

As with all Selenium locators, there are no set-valued results (as with generic XPath), and each locator has to come up with at most one result element. Therefore, for each location step, the first match wins, i.e. if there are multiple children that match the current specification, the first child is taken as the root for the rest of the search. Backtracking is only done for wildcard (*) searches.

The qxhv= locator works just like qxh=, except that for each step, only qooxdoo widgets with the “visibility” property set to “visible” are considered. This means that no descendants of invisible container widgets will be found. In some cases, this can lead to unexpected results. For example, in many qooxdoo applications, the root folder of a qx.ui.tree.Tree is set to be invisible. In that case, the qxhv locator would never find the root node’s descendants, even though they are visible in the GUI.

The qxidv= locator searches for an HTML element with the given ID and looks at the qooxdoo widget it belongs to. Only if the widget is visible is the element returned, otherwise the locator will fail.