Faking a Password Field in JavaFX 1.2

I’ve been slowly attempting to migrate The Music Explorer from JavaFX 1.1 to 1.2. One area of the application that I was particularly looking forward to updating was the Twitter panel, which is the set of UI components that let you automatically Tweet your activity using the application.

Here’s what it currently looks like in the 1.1 version (on Windows):

It’s not exactly my proudest design moment, and if you haven’t checked out the Music Explorer yet, don’t let this deter you — it is visually the weakest part of the application.

In my defense, it looks this way because it mixes Swing components and JavaFX controls which made it all but impossible to line things up correctly. The second text box in particular is a wrapped Swing JPasswordField, which is unfortunately a slightly different size than the plain JavaFX text control above it.

“Oh, come on now”, you say. “It’s not that bad”.
Fine, check out how it looks on the mac:

Enough said.

So, clearly this needs its own sort of Extreme GUI Makeover: JavaFX 1.2 Edition.

Here’s what it looked like after I compiled it under JavaFX 1.2 (with no code changes):

Oops. That looks much worse, although I like the blue highlight and visible cursor in the new text control. Clearly, though, Swing and JFX Controls are just not going to get along - ever. So after replacing all the Swing components with 100% Certified JFX Controls and Layout Managers, here’s what it looks like:

Much better. Notice the “prompt text” on the text controls which solves the lack of labeling problem.

So now the hard part in all this of course, is that the second text box is a password field, yet since JavaFX still doesn’t currently have such a widget, anything typed into that field will show up as clear text.

So this problem jogged my memory to a post on Drew’s Blog (which btw, is a great source for quality JavaFX posts) who solved this problem by blurring the contents of the text field. Since that’s a pretty neat idea, I went ahead and did that here:

And here’s the code that makes that happen:

TextBox {

promptText: "Password"

columns: 15

effect: bind if (password.rawText.length() > 0) BoxBlur {} else null

}

Note that the password field isn’t blurred until the user starts typing, which means that if the “prompt text” is visible, it’s not blurred.

This relies on a couple of (perhaps shaky) assumptions to work. The first is that, according to the API docs, the value of “rawText” will be updated with every key stroke if the underlying system supports it otherwise it won’t be updated until the user “commits” the text (by navigating off the field for example). Meaning that it’s possible on some systems for the “blur” to not kick in until the user finishes typing (which would miss the point of obfuscating the password).

The second potential code smell here is a possible performance issue with the bind. I don’t know the mechanics of how the bind works, but if it gets evaluated every time “rawText.length()” changes (as opposed to the entire expression “rawText.length() > 0″, which will only change once), then it will get fired every key stroke. This might be alright though, if assigning the “effect” is an inexpensive operation (which I assume it is).

Another way to do this could be to register an “onKeyPressed” handler which would simply assign the effect on the first down stroke.

So there it is. Thanks again to Drew for the idea.