Closed Bug 265854 Opened 20 years ago Closed 19 years ago

Find Toolbar's close button is now too far to the left

Categories

(Toolkit :: Find Toolbar, defect)

defect
Not set
minor

Tracking

()

RESOLVED WONTFIX

People

(Reporter: nospam, Assigned: bugzilla)

References

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20041023 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20041023 Firefox/1.0

Bug 250648 moved the find toolbars' close button the the left of the toolbar.
This is now inconsistent with the sidebar, tab bar, the missing plug-in
notification, and the blocked popup notification.

This was done to reduce the amount of mouse miles a mouse savvy user must travel
to click it.

But the reporter of bug 250648 stated:
"Ideally, there should be a close button (and it actually reads "Close", it's
not just an "X") to the right of the last "Highlight" button, possibly after a
toolbar separator.  This is very much like that found in the toolbar in the
Print Preview screen."

Instead the X has been put to the left of find.

I think it should either be put to the right of "Match Case" or back to the far
right.

It's probably inconsistent with the guidebook now as well.

Reproducible: Always
Steps to Reproduce:
Press CTRL+F
Attached image Screenshot
This is what it would look like to the right of Match Case.
Depends on: 250648
No longer depends on: 250648
Depends on: 250648
That, and the fact that it is smaller than the Windows close icon.
It has always been said that one of the largest issues with regard to widespread
public adoption of a software product is consistency and friendliness of the UI.
I find both the current (left-aligned) and proposed (somewhere in the middle)
behaviors to be inconsistent with parallel designs both within Firefox and in
other applications.

Ideally the user should already know where the button is before looking for it
and on Windows and Linux, the close buttons are on the top right corner of
windows and dialogs. With this in mind, I see no alternative to putting the
close button for the find bar back on the right side as it was up until 0.10+.
Now if the devs want to leave it on the left for Mac builds only, that's fine
and makes sense with respect to that OS's design.

I think this is the best decision because the alleged ease of use argued by
those that got it changed isn't as important as the universal consistency
demanded by the public at large. I found no extreme difficulty clicking on the
button when it was on the far right and users can remember that it is also
possible to close the bar with a simple press of the ESC button.
I just came to bugzilla to post this problem. The close button on the find bar
should most definitely be on the far right, to maintain consistency with the
close button on the tab bar, as well as the close button on the "Firefox has
prevented a popup from opening" bar, the "Firefox prevented this site from
installing software" bar, and the "Additional plugins are required" bar.
Flags: blocking-aviary1.0?
Severity: trivial → normal
OS: Windows 2000 → All
Hardware: PC → All
Flags: blocking-aviary1.0? → blocking-aviary1.0-
The close button on the left side makes no sense, in a Windows environment.
Besides the fact that Windows has the window close button on the right side, the
close button on the tab bar is also on the right. It's just common sense and
smart UI programming to have the find bar close button also on the right side. 
*** Bug 274588 has been marked as a duplicate of this bug. ***
WONTFIX ?
Flags: blocking-aviary1.1?
I think we can live with the trivial inconsistency here, its clearly visible and
not a burden to usability, IMO.  WONTFIX, but that isn't a guarantee that we'll
never change this, we may rework the find design in the future and this could
change.
Severity: normal → minor
Status: NEW → RESOLVED
Closed: 19 years ago
Flags: blocking-aviary1.1? → blocking-aviary1.1-
Resolution: --- → WONTFIX
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.