3

I'm running a set of automated UI tests using Appium/Winappdriver on Windows 10. The test framework is compiled in Visual Studio 2017 using mstest.

The problem that I am having is with tests that use a right-click to open a context menu, then select an element from the resulting menu. Locally, it works. It also works on our remote CI/CD machine. However, it does not work for the other two developers on the project, and we've spent two business days fruitlessly trying to figure out why.

We have the same Windows version (Windows 10, version 1903), we have the same Visual Studio 2017 (we also tried it with 2019, no luck), we have the same monitor resolution (1920 x 1080), we are targeting the same .NET framework (4.72), we have the same WinAppDriver, etc.

Everything else works just fine. But when the UI Test reaches that context menu, the test fails with the error "An element could not be located on the page using the given search parameters."

I used the WinAppDriver UI Recorder to find the XPath for the element. We also used it on the other user's machine and confirmed that, as far as the UI Recorder is concerned, the path is identical on both machines.

The specific call that fails:

Session.FindElementByXPath("/Pane[@ClassName=\"#32769\"][@Name=\"Desktop 1\"]/Menu[@ClassName=\"#32768\"][@Name=\"Context\"]/MenuItem[@Name=\"" + itemName + "\"]");

The WinAppDriver call on my machine (success):

{"using":"xpath","value":"/Pane[@ClassName=\"#32769\"][@Name=\"Desktop 1\"]/Menu[@ClassName=\"#32768\"][@Name=\"Context\"]/MenuItem[@Name=\"New Location\"]"}
HTTP/1.1 200 OK
Content-Length: 125
Content-Type: application/json

{"sessionId":"8970FDC1-E869-4304-A87D-D8F2CB711EA2","status":0,"value":{"ELEMENT":"42.856234.4.-2147483646.8140.18614751.1"}}

and the same call on the other user's machine (fail):

{"using":"xpath","value":"/Pane[@ClassName=\"#32769\"][@Name=\"Desktop 1\"]/Menu[@ClassName=\"#32768\"][@Name=\"Context\"]/MenuItem[@Name=\"New Location\"]"}
HTTP/1.1 404 Not Found
Content-Length: 139
Content-Type: application/json

{"status":7,"value":{"error":"no such element","message":"An element could not be located on the page using the given search parameters."}}

Again, everything else works. Other UI tests that don't use the right-click context menus work just fine. It's only this particular area that fails.

What I've tried so far:

  1. Using Thread.Sleep to force a long wait before making the call
  2. Wrapping the call with a DefaultWait and polling it over a period of several seconds to see if the element becomes available during that time.
  3. When the "An element could not be located" is thrown, retry up to a set number of times to find the element.
  4. Lots and lots of double-checking to make sure we're both on the same version of the code, same libraries, same nuget packages, etc.
  5. Trying a much broader locator ( Session.FindElementByName(itemName); )

The biggest head-scratcher is that when we check with UI Recorder, the element is there. When we check on my machine or the remote build machine, WinAppDriver can find it normally. But for some reason WinAppDriver can't find it on my coworker's machines.

NuclearWombat
  • 31
  • 2
  • 1
    So I found a workaround, which was to just send keystrokes directly to the keyboard instead of trying to click on the element. Not ideal, but it let me proceed. Still no idea why the app couldn't find the element even though it was visible in the UI Recorder. Tentatively thinking that the context menu somehow existed in a separate window handle, in which case the xpath would be correct but I'd still be searching in the wrong place. – NuclearWombat Oct 03 '19 at 15:15

3 Answers3

0

This is a peculiar issue indeed.

I'd like to rule out the XPath selector as a potential problem here. Based on your syntax, it looks like you are using an absolute XPath. These can be extremely brittle depending on the circumstances. Not saying it's the root problem, but I would like to try a different selector to rule this out.

{"using":"xpath","value":"//MenuItem[@Name=\"New Location\"]"}

Using relative // notation tells your path to look anywhere on the page, rather than following a specific path down to the element itself.

Give this a try, and let me know if it helps at all.

CEH
  • 5,701
  • 2
  • 16
  • 40
  • That didn't fix the issue, but oddly enough it *did* allow me to reproduce the issue locally. Which is confusing, since I would think that using a broader selector would be more likely to find an element, albeit not necessarily the correct one. – NuclearWombat Oct 02 '19 at 14:10
  • @NuclearWombat If you are reproducing the issue locally, the XPath is probably just plain wrong then :) I'm not sure if WinAppDriver supports relative XPath notation here. If it did, `//MenuItem` would find the same thing as the path in your original code. But, at least we have ruled that option out. – CEH Oct 02 '19 at 14:12
0

For my application context menu is listed out of the DOM of actual application in inspect.exe. So switching back to desktop session after selecting the context menu worked fine for me.

var regressionChannelRow = labelProcessorSession.FindElementByName("5000");
Actions action1 = new Actions(labelProcessorSession);
regressionChannelRow.Click();
action1.ContextClick(regressionChannelRow).Perform();

Now creating a desktop session to get the "Stop" option from the context menu

AppiumOptions appCapabilities = new AppiumOptions();
appCapabilities.AddAdditionalCapability("app", "Root");
WindowsDriver<WindowsElement> desktopSession;
desktopSession = new WindowsDriver<WindowsElement>(new Uri("http://127.0.0.1:4723"), appCapabilities);

below is the context menu option which I need to select, remember to use desktop session here

var stopService = desktopSession.FindElementByName("Stop");
stopService.Click();
Kanthu
  • 1
  • 4
0

I've just replicated this issue. I was working on a test that I wrote last week, which was now getting stuck trying to find the context menu from a desktop session. I tried using various XPaths, searching by class name or just name, but it didn't seem to make any difference.

Eventually I tried closing Spotify, and that solved the issue! If you're experiencing this problem then try closing every application window possible.

John Delaney
  • 53
  • 5