selenium: [πŸ› Bug][java]: Switching base64 decoder to a strict mode is going to break the compatibility with various Appium drivers

What happened?

Inclusion of https://github.com/SeleniumHQ/selenium/pull/11107 into the lib release is going to create issues with Appium driver compatibility. Some of these drivers are returning screenshots being base64-encoded with line breaks, which is against RFC4648 standard, but still complies to RFC2045. Calling Base64.getDecoder().decode would throw an exception for such blobs, while Base64.getMimeDecoder().decode would not (RFC4648-encoded blob could still be properly decoded properly by the MIME decoder though).

We did update Appium drivers to return screenshots in RFC4648, although older versions of them still use the old method. And we cannot limit newer client versions to be used only with newest driver releases. That is why my proposal would be to revert the above PR and let the client to accept both standards, even though the w3c standard is being strict about that.

How can we reproduce the issue?

See above

Relevant log output

None

Operating System

Any

Selenium version

4.5.0+

What are the browser(s) and version(s) where you see this issue?

Any

What are the browser driver(s) and version(s) where you see this issue?

Any

Are you using Selenium Grid?

No response

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 15 (10 by maintainers)

Most upvoted comments

I’m somewhat sympathetic to maintaining backwards compatibility, but we’ve pushed hard to be completely standards compliant. If we revert the change to the non-compliant option it has to be a temporary fix; i.e., we need a better long-term plan than β€œwait a year.”

Well, cloud providers should have relative recent versions available. Which is why I was asking what is the timeline/deadline where we can use only the spec-compliant mode?