On Wed, 23 Jun 2021 20:33:57 GMT, Phil Race <p...@openjdk.org> wrote:
> So the accessible text is just the right number of "echo" chars. Yes. > And you are still calling getPassword() just so you can find out the length. > Then it is over-written. There's a really tiny window after getPassword() and > before Arrays.fill() when the clear password is still there. Yes. But not as a string - and the window of opportunity to get the characters before they are overwritten by the echo characters is minimal. > The number of "char"s isn't the same as the number of "characters" if there's > a non-BMP code point in there .. Since in order to enter non-BPM characters you have to have an input methods helper which should be disabled on password fields for obvious reason - it would pretty much disclose the typed password in the IM helper window > perhaps these are not allowed by this class .. but it makes me wonder how > much if having the exact number of echo chars as the actual password is > important. I wonder how many text-to-speech readers can say "bullet" for a > unicode bullet character ? Well, accessibility is not only about text to speech - it is also about easier navigation so having exact number of the bullets is preferable. There are limitations - like some non-BPM text can be pasted into the password field and then navigating within it might be broken but since there will be no IM engaged fixing it would be equally problematic. > If it weren't for all of this (the class and the getPassword() method being > non-final I'd suggest you look into a way to pull just the length rather than > the actual chars. That would be preferable but under the current circumstances i would say that my fix makes things better without adding incompatible changes. ------------- PR: https://git.openjdk.java.net/jdk17/pull/127
