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.

[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?

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.

Yeah, that is obvious. I am asking for your preference since I can bring back the missing fields in Selenium but we still need to fix it here. Let me know what you prefer so I can help.

[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.

Yeah, that is obvious. I am asking for your preference since I can bring back the missing fields in Selenium but we still need to fix it here. Let me know what you prefer so I can help.

If selenium is not released yet that it definitely makes sense to bring fields back. If already released then I don't see much options going forward 🤷

[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?

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.

Yeah, that is obvious. I am asking for your preference since I can bring back the missing fields in Selenium but we still need to fix it here. Let me know what you prefer so I can help.

If selenium is not released yet that it definitely makes sense to bring fields back. If already released then I don't see much options going forward 🤷

It has not been released and I just merged SeleniumHQ/selenium#18098

So, should we send a PR here to fix it for future versions when we remove those fields in two releases?

[mykola-mokhnach]

depends on how we want to proceed further. if selenium package still does not follow breaking changes versioning policy then it does not make much difference whether we bump the minimum version of selenium dependency now or later.

[diemol]

depends on how we want to proceed further. if selenium package still does not follow breaking changes versioning policy then it does not make much difference whether we bump the minimum version of selenium dependency now or later.

This has been discussed several times, and if you want to bring the topic again, please drop by our Slack. I am offering to help and keep the package working well by making the changes here as well. Please tell me if I should send a PR or not.

[mykola-mokhnach]

Thanks for restoring the fields in selenium lib. You are welcome to create the follow-up PR, any contribution is appreciated.