Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[java] use the correct base64 decoder #11107

Merged
merged 1 commit into from
Oct 12, 2022

Conversation

joerg1985
Copy link
Member

Description

Use the correct base64 decoder (RFC4648) as defined by the WebDriver specification.

Motivation and Context

Selenium should follow the WebDriver specification

Types of changes

  • Bug fix (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 change)

Checklist

  • I have read the contributing document.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

The slightly wrong decoder was used to decode base64, using this decoder
will copy the byte array at the end of decoding. Using the correct one,
based on the W3C WebDriver specification, will not copy the byte array
after decoding it.
@codecov-commenter
Copy link

Codecov Report

Base: 52.31% // Head: 52.31% // No change to project coverage 👍

Coverage data is based on head (2d148c7) compared to base (9e91560).
Patch has no changes to coverable lines.

❗ Current head 2d148c7 differs from pull request most recent head cf4986f. Consider uploading reports for the commit cf4986f to get more accurate results

Additional details and impacted files
@@           Coverage Diff           @@
##            trunk   #11107   +/-   ##
=======================================
  Coverage   52.31%   52.31%           
=======================================
  Files          82       82           
  Lines        5503     5503           
  Branches      198      198           
=======================================
  Hits         2879     2879           
  Misses       2426     2426           
  Partials      198      198           

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

@sonarqubecloud
Copy link

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

0.0% 0.0% Coverage
0.0% 0.0% Duplication

Copy link
Contributor

@pujagani pujagani left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @joerg1985 !

@pujagani pujagani merged commit 877c34d into SeleniumHQ:trunk Oct 12, 2022
@weikilla
Copy link

hi , why do this change? i am using appium java client, which is depend on this project. but currently, when i call screenshot method, will throw Illegal base64 character xxx, i found the root cause is this change.

@joerg1985
Copy link
Member Author

@weikilla the W3C WebDriver specification does specify the Base64 decoder to use, see: https://www.w3.org/TR/webdriver/#index

I think you should open a ticket at appium to get this fixed in the corresponding driver.
Alternatively they could overwrite the selenium implemenation, if they need a none W3C compliant implementation.

Just my two cents, the selenium team might have a different opinion on this 😄

@mykola-mokhnach
Copy link

mykola-mokhnach commented Oct 25, 2022

This change will break the backward compatibility between following java client versions and existing Appium drivers. We'd have to hack this implementation in Appium java client to workaround it.

Even if we update the thing for multiple drivers, existing versions of them stay unchanged and there would be a mess.

cc @diemol @titusfortner @valfirst @SrinivasanTarget

@titusfortner
Copy link
Member

@mykola-mokhnach can you please create an issue to make sure we track this? I don't understand the difference in implementations, so I'd vote for reverting it in the next release and figuring out a better path forward if we need to make the change.

@mykola-mokhnach
Copy link

@titusfortner created #11168

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants