fix: fall back to standard error mapping in ErrorCodesMobile.getExceptionType(String)

[diemol]

Change list

• ErrorCodesMobile.getExceptionType(String) now calls super.getExceptionType(...) for states that don't match a mobile-specific error, instead of returning null.
• Added a null check on the incoming state to avoid a NullPointerException at message.contains(...).
• Added ErrorCodesMobileTest unit tests.

Types of changes

What types of changes are you proposing/introducing to Java client?
Put an x in the boxes that apply

• No changes in production code.
• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Details

ErrorCodesMobile overrides both lookup methods from Selenium's ErrorCodes, but they behave differently:

• getExceptionType(int) handles NO_SUCH_CONTEXT and delegates everything else to super.
• getExceptionType(String) handles "No such context found" and returns null for everything else.

Until now this didn't matter, because Selenium's ErrorHandler (which AppiumDriver installs with new ErrorHandler(new ErrorCodesMobile(), true)) resolved exceptions using the integer status. Selenium is moving ErrorHandler to the W3C state string instead (SeleniumHQ/selenium#18059, part of removing JSON Wire Protocol leftovers in SeleniumHQ/selenium#17638). After that change, every standard error, such as "no such element" or "stale element reference", would get null from this method. Appium users would then see a plain WebDriverException instead of NoSuchElementException, StaleElementReferenceException and so on, which breaks catch blocks and waits that rely on the specific type.

With this change, the String lookup behaves the same way as the int lookup:

new ErrorCodesMobile().getExceptionType("no such element");       // NoSuchElementException (was null)
new ErrorCodesMobile().getExceptionType("No such context found"); // NoSuchContextException (unchanged)

The new tests fail on the current code (expected: NoSuchElementException but was: null) and pass with this fix.

Selenium will keep a fallback for existing Appium releases on its side, so this isn't urgent, but it makes the method correct for the upcoming change.

🤖 Generated with Claude Code

[diemol]

I was going to merge the linked PR but Claude found that this would break Appium's errors codes. I will merge the PR in Selenium and I hope you folks can do a release soon with this change.

[mykola-mokhnach]

Thanks @diemol

It looks like the compatibility with the latest snapshot is already broken: https://github.com/appium/java-client/actions/runs/35845286236/job/107136595938, so only this change won't be enough to keep it compatible

[diemol]

Thanks @diemol

It looks like the compatibility with the latest snapshot is already broken: https://github.com/appium/java-client/actions/runs/35845286236/job/107136595938, so only this change won't be enough to keep it compatible

Let me check that, I think we made a change and removed some fields. Do you want me to bring them back in Selenium and deprecate them or should I send a PR here fixing them?

[mykola-mokhnach]

Thanks @diemol
It looks like the compatibility with the latest snapshot is already broken: https://github.com/appium/java-client/actions/runs/35845286236/job/107136595938, so only this change won't be enough to keep it compatible

Let me check that, I think we made a change and removed some fields. Do you want me to bring them back in Selenium and deprecate them or should I send a PR here fixing them?

fixing it here won't help from the perspective that end users would still have to update their selenium api version in order to make it compatible.