On Thu, 24 Jun 2021 04:39:12 GMT, Alexander Zuev <kiz...@openjdk.org> wrote:
>> src/java.desktop/share/classes/javax/swing/JPasswordField.java line 634: >> >>> 632: Arrays.fill(password, getEchoChar()); >>> 633: String text = new String(password); >>> 634: return new AccessibleTextSequence(0, password.length - >>> 1, text); >> >> So the accessible text is just the right number of "echo" chars. >> 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. >> The number of "char"s isn't the same as the number of "characters" if >> there's a non-BMP code point in there .. 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 ? >> >> 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. > >> 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 - the > only way to enter such symbols would b copy/paste and in this case i do not > expect it to be edited within password field. > >> 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. Why not use the "getDocument().getLength()"? ------------- PR: https://git.openjdk.java.net/jdk17/pull/127
