Closed Bug 399820 Opened 16 years ago Closed 16 years ago

Native GTK look for find toolbar


(Toolkit :: Find Toolbar, defect)

Not set





(Reporter: micmon, Assigned: ventnor.bugzilla)




(2 files, 4 obsolete files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20061201 Firefox/ (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.
Summary: Find toolbar button order → Native GTK look for find toolbar
Attached patch Patch (obsolete) — Splinter Review
This will reverse the buttons on GTK and use stock icons for the buttons.
Assignee: nobody → ventnor.bugzilla
Ever confirmed: true
Attachment #290177 - Flags: review?(mano)
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!
Attached patch Patch 2 (obsolete) — Splinter Review
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.
Attachment #290177 - Attachment is obsolete: true
Attachment #290263 - Flags: review?(mano)
Attachment #290177 - Flags: review?(mano)
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?
Attachment #290263 - Flags: review?(mano) → review-
Attached patch Patch 3 (obsolete) — Splinter Review
Attachment #290263 - Attachment is obsolete: true
Attachment #291515 - Flags: superreview?(mano)
Attachment #291515 - Flags: review?(mano)
Attachment #291515 - Flags: superreview?(mano)
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.
Attached patch Patch 3.1 (obsolete) — Splinter Review
Uses -moz-box-direction. Would you be able to get a review done before the freeze tonight?
Attachment #291515 - Attachment is obsolete: true
Attachment #291591 - Flags: review?(mano)
Attachment #291515 - Flags: review?(mano)
Comment on attachment 291591 [details] [diff] [review]
Patch 3.1


r=mano otherwise.
Attachment #291591 - Flags: review?(mano) → review+
Attached patch Patch 3.2Splinter Review
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.
Attachment #291591 - Attachment is obsolete: true
Attachment #291701 - Flags: approvalM10?
Attachment #291701 - Flags: approval1.9?
Comment on attachment 291701 [details] [diff] [review]
Patch 3.2

approvalM10-.  We'll get this in after beta2.  Thanks for the patch Michael.
Attachment #291701 - Flags: approvalM10? → approvalM10-
Attachment #291701 - Flags: approval1.9? → approval1.9+
Keywords: checkin-needed
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
RCS file: /cvsroot/mozilla/toolkit/themes/gnomestripe/global/findBar.css,v
Checking in toolkit/themes/gnomestripe/global/findBar.css;
/cvsroot/mozilla/toolkit/themes/gnomestripe/global/findBar.css,v  <--  findBar.css
initial revision: 1.1
Checking in toolkit/themes/gnomestripe/global/;
/cvsroot/mozilla/toolkit/themes/gnomestripe/global/,v  <--
new revision: 1.18; previous revision: 1.17
Closed: 16 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3 M11
Version: unspecified → Trunk
Find entry has no focus. Should I file new bug?
Product: Firefox → Toolkit
Depends on: 481397
You need to log in before you can comment on or make changes to this bug.