User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b4pre) Gecko/2008021104 Minefield/3.0b4pre Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b4pre) Gecko/2008021104 Minefield/3.0b4pre I believe the "Next / Previous" lozenge button is in an illogical order - in fact, the reverse order that it should be. IMHO, it would be more logical to have "Previous, Next". I believe it as established UI paradigm that with such button pairs (or lozenge-style buttons on OS X) the element to the right will initiate a go-forward action, and similarly the element to the left a go-back action. The current design of the Find Toolbar breaks this paradigm. Changing to a "Next/Previous" button would make this button consistent with the page backward/forward navigation scheme itself. Reproducible: Always Steps to Reproduce: 1. Open a webpage. 2. Press Cmd + F, or click Edit / Find. Actual Results: A Find Toolbar appears at the bottom of the screen. The buttons "Next / Previous" are displayed. Expected Results: A Find Toolbar appears at the bottom of the screen. The buttons "Previous / Next" are displayed.

Doesn't block. Might even be WONTFIX, need to think about that. Next is the more common action, and these don't clearly map to back/forward.

To illustrate how unnatural the current order is, imagine using left/right arrows rather than words. They would point at each other: > < Suggested fix: put them in logical order but use left/back arrows matching the history control rather than the words. That would make the Next value closer to the search field. Safari does this and its much more user friendly. Less ideal fix: use a Firefox 2 style of separate buttons with up/down arrows. But why waste all that space when users are already familiar with the history control (even outside of the keyhole container). I don't see how Next being the more common action changes anything, because: 1) Firefox automatically selects the first match, so the user is already changing what they're looking at and needs to reorientate themselves to move the next match via the GUI (which would benefit from arrows like the history control in making it quicker to visually re-acquire the location of the button). 2) Users who care about speed are using key commands to activate Find _and_ to Find Again. 3) Users who use the GUI, their mouse is up where the Find menu item used to be, nowhere near close to the next/previous buttons. 4) Tabbing doesn't select the next/previous buttons, so there isn't an extra tab stop when using logical order. 5) Showing arrows in the (keyhole) history control but not in the search control is inconsistent when the actions both mean virtually the same thing. If anything, I'd think the importance of Next would just warrant thoughts about how to apply the keyhole concept to this smaller control (such as keeping the keyhole shapes but without enlarging Next quite so much).

This is less of an issue on windows since we have the up and down arrows, but I agree that on OS X it feels a little odd.

I have the same problem on OS X. I've pushed the wrong button several time, and I think about "don't miss the right button" instead of what I want to do each time I use the find function...

(In reply to comment #3) > This is less of an issue on windows since we have the up and down arrows, but I > agree that on OS X it feels a little odd. This bug should block 565517 ;-) (In reply to comment #1) > Doesn't block. Might even be WONTFIX, need to think about that. Next is the > more common action, and these don't clearly map to back/forward. Maybe the solution is to use arrow on OSX too...

(In reply to comment #7) > This bug should block 565517 ;-) That's for limi to decide, but I've added the ux-natural-mapping keyword.

(In reply to Alex Faaborg [:faaborg] (Firefox UX) from comment #3) > This is less of an issue on windows since we have the up and down arrows, > but I agree that on OS X it feels a little odd. Searching heavily today for a work related activity for half an hour or so this bugged me on Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121113030658 so changing the platform to All...