Part of the Findbar design clean-up was moving the buttons to the right of the bar for some alignment with the similar infobars. The rationale for consistent infobar button placement doesn't really apply here so no reason to separate the functionality with a huge horizontal space.

Stephen, bug 565552 comment 55, is this what you meant by "alignment with infobars"? Admittedly, I never gave it much thought to the reasons it was made like this, until I saw this bug. The close button is definitely placed "correctly" in my view, and apparently that was the rationale for that change at least. I don't recall any other close button on the left of something at the moment, so this is definitely more consistent with the whole browser. As for the case and highlight buttons, I found the new design more intuitive to use, to be honest. Especially considering the find bar was originally to be moved to the top, the buttons on the right would be easier to distinguish than on the left, although with the find bar on the bottom that isn't completely false either. They are also "options"-related elements, and those are (at least usually) placed opposite from "usage"-related elements (such as the actual find field) when there are both; see the dev-tools and dev-toolbar, browser console, downloads sidebar or even the location bar. Please note that I'm just giving my opinion, I think the consistency with infobars rationale does apply because it applies (or should at least) to all kind of workable bars.)

Please remove the horizontal space from between the search field and buttons and put the close button back to the left side, because its very uncomfortable and waste of time to move the mouse through the whole screen to use the buttons. It's illogical! As it shown in the picture: http://cdn.userstyles.org/style_screenshots/95217_after.png Thank You!

I could not agree more Ferenc! I posted as much in bug 936858. This as well as bug 741277 makes a whole lot of sense.

(In reply to Luís Miguel [:Quicksaver] from comment #5) > As for the case and highlight buttons, I found the new design more intuitive > to use, to be honest. Especially considering the find bar was originally to > be moved to the top, the buttons on the right would be easier to distinguish > than on the left, although with the find bar on the bottom that isn't > completely false either. The main problem is the new bar is the form of the two togglable options. Look, you - among others - call them buttons. But they are not buttons. These are checkboxes disguised as buttons. This UI is absurd. In software UI, a button : - triggers an action - does not remain pressed Before, these two options were nice checkboxes.

As much as I hate to disagree with criticisms of the new find bar, there is no universal law that states buttons cannot remain pressed. Buttons that remain pressed are a one-stage toggle as opposed to a two-stage toggle, both of which I've seen in software UI (though the latter more often than the former). I can give plenty of hardware examples such as power buttons that stay pressed, but no immediate example comes to mind in regards to software UI. Highlight All and Match Case _do_ trigger actions; they change the search results or the presentation of the search.

(In reply to Luís Miguel [:Quicksaver] from comment #5) > The close button is definitely placed "correctly" in my view, ... definitely > more consistent with the whole browser. Consistent, but harder to use. Consider people with trackpads, or trackballs, or vision problems. They have to move the cursor all across the screen either to use the buttons or to close the tool. I find it a bit of a nuisance even with a mouse. The purpose of consistency is so it will be easy to find, but people will have no trouble finding controls if all controls are grouped together with the one field that they ALWAYS use.

"Match Case" is currently so far away from the search field on my 24" monitor that I don't even notice when it's on, which on occasion seriously messes up my work and wastes my time. I never even look at the lower right corner of the search bar, because I close it with the Esc key. (I don't even know why "Match Case" was on. I sure hope that's not the default.)

Yeah let's fix this. Super annoying paper cut.

I think the findbar container (http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/findbar.xml#159) should be align="start" 'ed in that case, or am I reading that wrong?

Bug 250648 10 years ago was the same. Stop looking for consistency everywhere. To quote Donald Knuth, http://xkcd.com/163 For those who can't wait, you can fix this bug using userChrome.css https://support.mozilla.org/fr/questions/976166

Comment on attachment 8405787 [details] [diff] [review] findbar-move Review of attachment 8405787 [details] [diff] [review]: ----------------------------------------------------------------- LGTM! I actually had the same patch in my MQ :-) No CSS changes are necessary and the `align=center` is still good.

I didn't see a commit message, please make sure you add a nice one ;)

(In reply to Mike de Boer [:mikedeboer] from comment #18) > No CSS changes are necessary and the `align=center` is still good. I think the hover styling of the buttons should be adjusted to match the one the navigation bar in Australis. Come to think of that, the bookmark bar icons and items need to be changed as well. This probably calls for a separate bug, though.

(In reply to jaramat from comment #20) > I think the hover styling of the buttons should be adjusted to match the one > the navigation bar in Australis. Come to think of that, the bookmark bar > icons and items need to be changed as well. This probably calls for a > separate bug, though. Hi jaramat! That's bug 891258, you might want to check it out ;)

Works/fixed/resolved Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0 BuildID 20140714151536 [bugday-20140716]