StalenessOf returns true for live element!

[DynConcepts]

The following ALWAYS returns true for the input tag....

Accessing the Parent via "/.." returns false.....

[DynConcepts]

Just pulled and searched the source... Confirmed this behavior... I believe this to be a BUG...

   public static Func<IWebDriver, bool> StalenessOf(IWebElement element)
    {
        return (driver) =>
        {
            try
            {
                // Calling any method forces a staleness check
                return element == null || !element.Enabled;
            }
            catch (StaleElementReferenceException)
            {
                return true;
            }
        };
    }

[jimevans]

Yes, the code would fail in that instance. It's one reason that use of the ExpectedConditions class is heavily discouraged in .NET, and one reason that the maintainer has expressed a huge regret at having ever implemented it in the first place.

[DynConcepts]

Jim, Just an observation... It took over 20 man hours (at over $200/hr) to isolate this....and that is just one teams experience. It is a trivial change to make it work...so why not simply fix it???

[ddavison]

If it's a trivial change, try your hand at a Pull Request @DynConcepts 👍 help us make the project better

[DynConcepts]

ddavison - alas there are some constraints at play... The fix is...

  try
        {
            // Calling any method forces a staleness check
            bool enabled = rawElement.Enabled;
            return false;
        }

[jimevans]

@DynConcepts Did I say I wouldn't be fixing it? I don't think I said that. In point of fact, I'm traveling today, and don't know if I will get around to it before at least next week. I'm sorry if my inability to be sitting at a working development environment to jump on fixing your particular issue within 10 minutes of having added a comment to it in the tracker does not meet your idea of a Service Level Agreement for a piece of software I volunteer my time and effort to, and you paid no money to use.

Frankly, it's not a high priority for me, because a dedicated ExpectedConditions class an ill-conceived concept for the .NET bindings. It was coded and implemented when slavishly offering a .NET analogue of every single piece of code offered by the Java language bindings was thought to be a good idea.

[DynConcepts]

Jim, That was not my intention at all, and you have my deepest apologies if it came across that in any way shape or form.

Out of curiosity, if that is the state of the class, why not deprecate it? [ObsoleteAttribute]....

I too spend a large amount of volunteer time, so I know exactly where you are coming from.

[jimevans]

It hasn't been marked with the attribute because, frankly, very few people actually use it. Most .NET developers opt to just use a lambda function directly when using WebDriverWait. Now that there is a proven case of an issue with these methods, I would expect a deprecation and removal before too long.

[barancev]

Closing in favour of DotNetSeleniumTools/DotNetSeleniumExtras#9