The field that stopped taking text

You are preparing a class. The ride isn't working for you, so you click “Clear ride” to start over. RideComposer asks you to confirm, and you do. Next you want to pick the class type: the list won't open. You click into a field to type a name: nothing appears.

The software doesn't look frozen — your clicks get through. But the keyboard doesn't.

And after a restart, everything works again.

We ran into this ourselves while preparing classes, over several days, without being able to make it happen on demand.

Why it was so hard to catch

A bug that happens “sometimes” is the worst kind: you don't know where to look. And this one kept changing shape.

On 2 October it was the ride name: you could place the cursor and delete, but not type. Switching to another view and back was enough to fix it.

On 6 October it was the tempo filter in the library: no cursor, no typing — only the field's small arrows worked. “In some folders yes, in others no”, we noted at the time. After a restart, it was gone.

We started by looking inside the software, and checked the most convincing explanations one by one. An invisible element sitting on top of the fields? None, in any of the 326 folders of the library we tested. A keyboard shortcut grabbing the digits? None. Something to do with the chosen folder? No: the problem went away on restart, in the same folder.

None of these checks fixed anything. But they kept us from shipping a fix for the wrong cause — one that would have looked like it worked, right up to the next time.

What we needed to look at: the step before

The breakthrough came from a simple question: what did you do just before it locked up?

On the evening of 6 October, the problem came back twice in a row, both times after the same step: “Clear ride”, then the class-type list. This time we could watch the software at the very moment it locked up, without restarting it.

Here is what we saw. As far as Windows was concerned, the RideComposer window was active. But the page inside it believed it wasn't — it no longer considered itself in front. And a page that thinks it isn't in front won't open its lists or accept typed text.

So the culprit wasn't in the ride, or in the library. It was Windows' little confirmation box — the one that asks “are you sure?”. When it closed, it handed the window back to RideComposer, but not the keyboard to the page.

We believe the 2 and 6 October episodes had the same origin, but we can't prove it after the fact: nobody had written down the step that came before them.

The fix, and the proof

The remedy is a few lines long: whenever one of these boxes closes, RideComposer now explicitly asks Windows to give it back control. The box still answers exactly as before; you won't notice any difference, except that the keyboard works.

We didn't want to settle for “seems fine”. So we reproduced the real bug, with a real Windows box, closed with the Enter key, and real keystrokes:

• before the fix: type “67” into the field, and it stays empty;
• after the fix: type “67”, and it appears.

If a field doesn't respond

This isn't the first time a field has been reported as “not working”. In September, the ride name looked as if it couldn't be edited. It could — but its cursor, with no border and no background, simply couldn't be seen against the bold title. Same symptom, completely unrelated cause.

If it happens to you, two pieces of information save us days: what you did just before, and what you see when you click — a blinking cursor, or nothing at all. That is exactly what led us to this one.

The fix has been in RideComposer since version 2.0.16. The current version, 2.0.18, is available from ridecomposer.com.