935519 - Move "Highlight All" and "Match Case" back next to find field

Status: RESOLVED FIXED

(Toolkit :: Find Toolbar, defect)

Description

[Stephen Horlander [:shorlander]]

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.

Comment 5

[Luís Miguel [:quicksaver] (not reading bugmail)]

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.)

Comment 6

[Ferenc Magyar]

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!

Comment 7

[Patrick Seiter]

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.

Comment 8

[Nicolas Barbulesco]

(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.

Comment 9

[Patrick Seiter]

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.

Comment 11

[VanillaMozilla]

(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.

Comment 13

[N. de Jonge]

"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.)

Comment 14

[Tom S [:evilpie]]

Attachment: findbar-move

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

Comment 15

[Luís Miguel [:quicksaver] (not reading bugmail)]

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?

Comment 17

[alliz_gub]

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 18

[Mike de Boer [:mikedeboer]]

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.

Comment 19

[Mike de Boer [:mikedeboer]]

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

Comment 20

[jaramat]

(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.

Comment 21

[Mike de Boer [:mikedeboer]]

(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 ;)

Comment 22

[Tom S [:evilpie]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/2c22636dd877

Comment 23

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/2c22636dd877

Comment 25

[Jan [:Jan\]]

Works/fixed/resolved

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0
BuildID 20140714151536

[bugday-20140716]