Betalogue

I always have Full Keyboard Access on on my machine, not because I suffer from repetitive stress injuries, but because I don’t like having to switch from the keyboard to the mouse and back all the time.

Because of this, I tend to notice problems that might not be apparent to Mac users who do not use Full Keyboard Access and that tend to suffer from a certain amount of neglect on the part of Apple’s engineers.

For example, a while ago I pointed out that the tab order for the various controls in Pages ’08’s “Find/Replace” dialog box was wrong. This was a problem that was only really apparent if you had Full Keyboard Access on and used the Tab key to cycle through all the controls in that dialog box, including not just the text fields, but also the pop-up menus, the buttons, etc.

Thankfully, Apple fixed the tab order in Pages ’09.

But there is still another problem with Full Keyboard Access in the “Find/Replace” dialog box that remains unaddressed in Pages ’09. It has to do with the behaviour of keyboard shortcuts when the focus is on a control other than a text field.

For example, after having turned Full Keyboard Access on, bring up the “Find/Replace” dialog box, switch to the “Advanced” tab, and then type a text string in the “Find:” field.

Then press command-A to select the text string you’ve just typed and press command-C to copy it to the Clipboard. While the focus is on the text field, these two keyboard shortcuts work just fine.

Now press the Tab key repeatedly to move the focus to the “Replace:” field, with the intention of pasting the contents of the Clipboard once you’re there. If you have Full Keyboard Access on, it takes quite a few Tab keystrokes to get there, because Tab cycles through all the controls and not just the main ones.

So it’s relatively easy to overshoot or undershoot by one keystroke. So let’s say that, accidentally, you press the Tab key one time too many and you end up putting the focus on the “Insert…” pop-up menu next to the “Replace:” field, rather than on the “Replace:” field itself:

Now if, like me, you tend to work fast and do this type of thing repeatedly throughout the day, you might do the next step, i.e. press command-V to paste the contents of the Clipboard, before you actually notice that the focus is on the wrong control.

And that’s where things get, let’s say, interesting. Since the focus is on the “Insert…” pop-up menu and not on the “Replace:” text field, Pages ’09 should just ignore the command-V shortcut, since it has no relevance when the focus is not on a text input area.

But it does not. Instead of ignoring the shortcut, Pages ’09 actually inserts the contents of the Clipboard in the main document window in the background behind the “Find/Replace” dialog box!

And the problem is not just limited to the command-V shortcut. If the focus is on the “Insert…” pop-up menu (or another control in the dialog box that is not a text input area) and you press command-A, again instead of ignoring the shortcut Pages ’09 selects the entire contents of the main document window in the background behind the “Find/Replace” dialog box.

So clearly there is a focus problem here. Even though the “Find/Replace” dialog box is very much in the foreground and keyboard shortcuts apply to it and be ignored if they are not relevant, when the focus is on a control that is not a text input area, Pages ’09 wrongly and invisibly switches the focus back to document window in the background.

I believe it’s quite clear that this is the wrong behaviour, even though the “Find/Replace” dialog box is not a modal dialog box and can indeed be left open in the background, with the focus back on the document window. Regardless of this modal flexibility, when the dialog box is in the foreground, keyboard shortcuts should apply to that foreground window exclusively, and be ignored (with a system beep if necessary) if they are not relevant.

It might seem like a minor thing but when, like me, you tend to work fast and try to execute a sequence of keyboard shortcuts in one fell swoop, it’s easy to overshoot. If Pages ’09 behaved properly in this situation, the damage caused by the overshooting would be minimal and easy to undo. Instead, when what I described above happens, you have to switch back to the document window to manually undo what Pages ’09 has just done. And when you repeat the same thing dozens of times during the same day, it can get quite frustrating.

It’s another issue to add to the already long list of issues with Pages ’09’s “Find/Replace” dialog box, as mentioned in my other post earlier this week, which really seems to suggest that Apple’s engineers have not spent much time actually trying to use this dialog box.

I am not about to turn Full Keyboard Access off, because it’s too useful for me. But I also know that I probably will have to live with this problem for a while, because Full Keyboard Access-related issues tend to have a relatively low priority at Apple. (Remember how long it took them to fix iTunes so that it would work properly with Full Keyboard Access.)

If the problem bothers you as much as it bothers me (and even if it does not!), I strongly urge you to submit it to Apple via the Bug Reporter.

This entry was posted by Pierre Igot on Friday, June 5th, 2009 at 9:47 am and is filed under Pages. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.