User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20061201 Firefox/2.0.0.3 (Ubuntu-feisty) Build Identifier: The current layout of the Find toolbar is [close] [ Search word ] [V Next] [A Previous] ... I think changing this layout to the following would make sense: [close] [ Search word ] [< Previous] [> Next]... IMHO the second order is much more natural. Speaking for the Linux platform at least, all applications I know which make use of similar find bar use the this layout. See the screenshot for the find bars of the Epiphany Webbrowser, Evince Document Viewer, Yelp Help Browser and Tomboy, the note taking app (all of which are GNOME core applications) So consider changing this for the Linux builds at least, to make Firefox behave more like the rest of that platform's applications (I don't know windows apps, so I can't say how it is handled there). Reproducible: Always

With the aim of OS integration for FF3, this bug is becoming very relevant. We should swap the buttons for GTK builds, drop the icons and add native GTK arrows.

This will reverse the buttons on GTK and use stock icons for the buttons.

Nice, but can't we use "native" looking GTK arrows instead of the icons? It would look very clean, if we also move the arrow for "Next" to the right side of the label: [close] [ Search word ] [< Previous] [Next >]... Anyway, thanks for all the great work you are doing!

I don't think I can do that with just theming CSS. This second patch provides better feedback for a pressed Highlight button, since we are using a stock icon for that now and the icon cannot glow anymore.

Well, it is possible to put the "icon" on the right side of the button. As for the GTK-like arrows, I think having something like moz-appearance: arrowleft/arrowright/arrowdown/arrowup would be great. As the list header sort arrow is already drawn this way it has to be possible... and it could then be used here, as well as in the menus (for submenus) as well as the toolbar.

Comment on attachment 290263 [details] [diff] [review] Patch 2 can you put the buttons in a box and reverse the order from gnomestripe's findbar.css?

Sure.

Where's the corresponding style rule?

(In reply to comment #9) > Where's the corresponding style rule? > What do you mean? I put the buttons in the box and set -moz-box-ordinal-group on both buttons. The box doesn't need a style rule, unless I'm missing something...

Ah, I thought you'd be using -moz-box-direction: reverse.

I didn't know about either CSS rule, it was Roc who told me about -moz-box-ordinal-group :-) So is this an r+ or do I have to use the latter rule?

I think the later is cleaner given that you already have a box.

Uses -moz-box-direction. Would you be able to get a review done before the freeze tonight?

Comment on attachment 291591 [details] [diff] [review] Patch 3.1 s/find-button-/find-buttons-/ s/0px/0/ r=mano otherwise.

WHile not critical, this patch is very trivial and will cause another major part of the UI to use the already tried-and-tested stock icon infrastructure. Since this is only XUL and CSS I can't imagine any risk whatsoever... Since Linux UI consistency is a very, very major feature in B2 this patch would be icing on the cake.

Comment on attachment 291701 [details] [diff] [review] Patch 3.2 approvalM10-. We'll get this in after beta2. Thanks for the patch Michael.

Checking in toolkit/content/widgets/findbar.xml; /cvsroot/mozilla/toolkit/content/widgets/findbar.xml,v <-- findbar.xml new revision: 1.18; previous revision: 1.17 done RCS file: /cvsroot/mozilla/toolkit/themes/gnomestripe/global/findBar.css,v done Checking in toolkit/themes/gnomestripe/global/findBar.css; /cvsroot/mozilla/toolkit/themes/gnomestripe/global/findBar.css,v <-- findBar.css initial revision: 1.1 done Checking in toolkit/themes/gnomestripe/global/jar.mn; /cvsroot/mozilla/toolkit/themes/gnomestripe/global/jar.mn,v <-- jar.mn new revision: 1.18; previous revision: 1.17 done

Find entry has no focus. Should I file new bug?