Exception retrieving TagName - Response from remote end doesn't have $.Value property

[jrod567]

Appium Server v2.18.0
uiautomato2 v4.2.4

When attempting to get the IWebElement.TagName property, the following exception is thrown:

Message: 
OpenQA.Selenium.WebDriverException : Response from remote end doesn't have $.Value property

Stack Trace: 
Response.EnsureValueIsNotNull()
WebElement.get_TagName()
AppiumElement.<get_TagName>b__6_0()
AppiumElement.CacheValue(String key, Func`1 getter)
AppiumElement.get_TagName()

IWebElement mode = drv.FindElement(MobileBy.XPath("//android.widget.TextView[@text='Modes']")); Log.Information("TagName: {T}", mode.TagName);

[KazuCocoa]

Please attach the full appium server log

[jrod567]

Here you go:

serverLog.txt

[KazuCocoa]

I guess... dotnet client in selenium expects the /name endpoint is non null.

Can you use GetAttribute instead as a workaround? It looks like appium dotnet client needs to override the behavior then.

https://github.com/SeleniumHQ/selenium/blob/33a673ed1f0333be414596a631e026302a11d676/cpp/webdriver-server/server.cc#L773
https://github.com/SeleniumHQ/selenium/blob/33a673ed1f0333be414596a631e026302a11d676/dotnet/src/webdriver/WebElement.cs#L80

[jrod567]

Yes, using GetAttribute will work though attributes will have to be specific per driver (android/ios); sort of defeats using the interface unfortunately.

[jrod567]

@KazuCocoa Any idea on how best to handle this? For instance, this issue seems better suited on the android end of things. For instance, this "works" but it's a total kludge:
`//public override string TagName => CacheValue("name", () => base.TagName)?.ToString();

public override string TagName => this.WrappedDriver is AndroidDriver ? GetAttribute("class") : CacheValue("name", () => base.TagName)?.ToString();`

[KazuCocoa]

Customizing the value handling only for AppiumElement#TagName might not be an intentional behavior as the original design of each appium client. Adding a new name of function in AppiumElement would be proper than changing the current behavior.

[Dor-bl]

@jrod567, Any reson you use IWebElement?
I use AppiumElement, and it works for me.

        public void TagName_WithCacheDisabled_ReturnsTagNameFromServer()
        {
            AppiumElement element = _driver.FindElement(MobileBy.AccessibilityId("Graphics"));

            var tagName = element.TagName;

            Assert.That(tagName, Is.Not.Null.And.Not.Empty);
        }

[jrod567]

@Dor-bl I use IWebElement for certain aspects of our own framework that spans across Appium and Selenium. Working at the IWebElement interface keeps this more generic. Since AppiumElement implements IWebElement, I wouldn't expect the hard exception and would expect it to return the AppiunElement.TagName property. Yes, AppiumElement.TagName works, but still think IWebElement.TagName should still be fixed for completeness in the dotnet client IMO.

[jrod567]

@Dor-bl I went back into this and looks like pulling TagName no longer throws the original exception (via AppiumElement or IWebElement - it was specifically an issue when underlying driver was AndroidDriver).

originally logged this issue prior to moving to v3 so this possibly worked itself out through a series of dependency changes.

That said, looks like AppiumElement.TagName value being returned for Android is incorrect (should be returning it's class vs. content-desc; iOS looks correct). Curious if you see the same issue or not. I'll open a new/different case on this issue once I get more time to investigate.

[Dor-bl]

Closing this out – per the last update, @jrod567 confirmed the original exception (Response from remote end doesn't have $.Value property when reading TagName) no longer reproduces, likely fixed through subsequent Selenium/dependency updates.

The separate, narrower concern raised there - AppiumElement.TagName returning the element's class rather than content-desc on Android - is a different issue and worth tracking on its own. @jrod567, please open a new issue for that with a repro if you get a chance; happy to pick it up there.