Tag Info

Bruce, welcome to SQA. The label in the element in question is AgendaShowCapacity (1 remaining), but the label in your XPath is AgendaShowCapacity (1 remaining). I am not sure a blank and an   are equivalent in an XPath. Have you tried replacing that first blank with an   in your XPath? Another way to rule out the   ...

Don't forget the not only performance is better with CSS locators, it's the compatibility too that matters. We are testing on a multy browser environment in which we use: IE, SAFARI, FIREFOX, CHROME. On IE the xpath almost never works OR it is SO slow that it can't be managed. So we use CSS where ever we can. Unfortunately IE does not support many CSS ...

This is the problem with Selenium IDE or any other recorder for that matter. It doesn't deal with dynamic data very well. If you really want to solve this problem without switching tools, you can try to use an xpath with an static anchor that's higher up in the DOM. For instance, you just start at //*[@id='edit_1_undefined'] and lets assume this element is ...

Did you try using regular expression or a substring in the xpath? Something like this may help: xpath = "//img[contains(@id,'x-auto')]" OR WebElement Estimates=webdriven.findElement(By.xpath("//img[contains(@id,'x-auto')]")); You can also use another xpath method starts-with(@id,'x-auto')

You can find an Xpath specification here. Your first xpath matches an anchor that contains exactly the string "test link". The last xpath matches an anchor whose contents includes the substring "test link". No doubt it is slower, but the depending on the circumstances, the performance difference may be insignificant. As far as I can tell, the first and ...

An example of something you can only do in XPATH is go the parent of the current node. So while I recommend using CSS when you can, sometimes XPATH is the only way. Edit : Actually, brain-fart on my side. The following site has two very useful charts that compare CSS and XPATH locators if those exist plus DOM locators for good measure, all with special ...

If there is an element above the button that is uniquely identifiable you could search only in that scope, assuming that the button is the only button in that scope. You could also try to partially match the button id (not sure if the entire thing changes, or just part of it) or match the button's class if it does not change. If there is no way to identify ...

I think that your page (or part of it) is reloaded after performing listName.click(). After reload there is also a table which seems to be same as that one from before reloading but it is not the same one. You can count rows/columns in the table and use iterators in your loops. You will need to repeat WebElement table = ...

From my experience, sometimes the way XPaths are read by Selenium are different from what you expect, especially if you've verified the XPaths are correct in Firepath. Yes, both of the XPaths you've posted point to the same element and should work identically, but for some reason, only the relative one is working correctly in the IDE. The main takeaway ...

Is it too obvious to use the "title" attribute? //td[@title='Shows data of bank account'] On a different note, you could also look at the parent element and identify it, then draw reference to the particular tab your after. E.g. if the cell td is within a table row: //tr[@foo=bar]/td[x] where x is the child xth td element of the tab your after.

As User246 mentioned, the xpath support depends on the browser. I have found a few problems with using XPath cross-browser. My solution for this problem was to find elements by tag name first, then iterate through the list of elements matching the tag and look for the attributes that I want to match on as well.

A few things to look at. Are you sure that the LinkText is correct? Are you missing spaces, non breaking spaces, etc that may appear in the html but you don't see as a user? Are you sure the xpath is correct? Is this a timing issue? Are you trying to find the elements before the page is finished loading or before those elements are loaded?

No jQuery will not be faster. IE has a very slow JavaScript engine compared to other modern browsers. Using jQuery selectors means you are using JavaScript to query the DOM, so you are instantly limited by IE's JavaScript engine. XPath support in IE is also via a JavaScript library (Google's wicked good xpath library), so XPath's will also be slow. The ...

css=a[text='Log Out'] or a[innertext='Log Out'] Can you please try this one out? Or if that doesn't work and you still don't want to use xpath because it's slow, you can always try: link=Log Out. That's still better then xpath. EDIT: So i found a possible solution for you mate. If you are trying to find an exact String you could always use Regular ...