find toolbar should be undockable




Find Toolbar
13 years ago
9 years ago


(Reporter: Vlad Beffa, Assigned: Blake Ross)


Firefox Tracking Flags

(Not tracked)




13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

The find toolbar should be undockable, the way it was in 0.x versions and the
way it is in IE. I would even go so far as to say it should be undocked by
default, and you can dock it if you want. Users are already used to this
behavior from IE and Netscape, and it's less constraining as well.

Reproducible: Always
Steps to Reproduce:

Comment 1

13 years ago
This would also help if there isn't enough space on the toolbar to put the
"match whole word only" option (see bug 269442).
This would be pretty difficult to do right, and doesn't offer any obvious
benefit, other than for users wanting a modal dialog for some strange reason.

Last Resolved: 13 years ago
Resolution: --- → WONTFIX

Comment 3

13 years ago
Can we get some more feedback first before we quickly brush this off? I've
explained the obvious benefits: IE/Netscape users are already used to a floating
search dialog, and it's less constraining to be able to move it around than to
have it at the bottom, where it's harder to see. If it's hard to make
undockable, then I still think it would be better to have just the original
floating dialog rather than the search toolbar at the bottom of the window. Most
other applications besides web browsers work this way too (e.g., Microsoft
Word). I see nothing strange about this.
The entire point of the Find Toolbar was to replace modal dialogs with a
flexible find setup that was more powerful than the simple find dialogs. 
Overall user reaction is extremely positive, and we're not going to revisit this
decision any time soon.  Just because something used to work a certain way
doesn't mean its the best solution.  We feel that the Find Toolbar is vastly
superior to previous Find incarnations, and most users agree.

Comment 5

13 years ago
I don't see how a fixed toolbar is more powerful than a floating dialog. Both
can provide the same search functionality. In fact, the current toolbar is less
powerful than, say, the IE find dialog, because it doesn't have a "Match whole
word only" option (bug 269442). The highlight functionality can be achieved in
IE if desired through the Google toolbar. (And incidentally, installing the
googlebar in Firefox causes the Find highlight feature to stop working (bug

But the point of this bug isn't the find functionality that is or isn't
currently provided, it's the placement of the find box. I agree that just
because something has been done a certain way doesn't mean it is the best way.
However, I believe from a UI perspective a floating find dialog is better, and I
was hoping to see some discussion on that point (for example, are there any
other applications that do it that way, why they do it that way, why the new way
is considered better, etc.).
You're not giving examples why a floating dialog is better.  You're just saying
it is, without providing any details why.  Despite my better judgement, I'll
give you details, although it won't make a difference in the end.  As I've said,
user feedback has been extremely positive, changing back would be considered a
regression by a majority of users.

Reason #1 why the toolbar is considered better that the traditional solution is
that it doesn't block content, ever.  Find boxes, especially bigger
multifunctional ones, can block significant parts of the content area.  While on
a sufficiently high-resolution monitor you can move it out of the way, that's
not an option for most users.

Reason #2 is that it is tab-independent and doesn't have to be
recalled/dismissed to interact with content.  Modal dialogs are generally poor
UI unless its absolutely essential that the rest of the app not be accessed
while the dialog is up.  This certainly isn't true for a search function.

Reason #3 is that it allows search terms to remain visible while interacting
with content/using find again shortcuts.  Having the ability to access content
while using highlight/next/previous is more flexible and powerful than recalling
a dialog and finding again.  Yes, keyboard shortcuts allow this either way, but
users generally don't use them.

Now if you really want to continue discussing this, feel free to refute my
points and provide arguments where the tradition modal dialog is superior.  Yes,
there are improvements to be made, but having a big modal dialog isn't the
answer either.

Comment 7

13 years ago
OK, here goes. The dialog is superior in control and flexibility, as explained
below. (By the way, I think you're assuming that the traditional find dialog is
modal. It isn't and shouldn't be--see 2 and 3 below for more.)

1. The toolbar does block content by shrinking the size of the visible page. A
floating dialog blocks content but conceptually it preserves the size of the
visible page. Also, a toolbar does not have a fixed size. Its size depends on
the browser's current size (and indirectly on the monitor's resolution). If more
functionality were to be added (like "Match whole words only"), would the find
toolbar be expanded to two rows (thereby doubling its size and the amount of
space it takes away from the current page), or would the additional
functionality just be added to the right of the current features? Currently, if
you make your browser window small enough, part of the find toolbar gets cut off
and there is no way to scroll it. There isn't currently enough functionality for
this to be an issue on even low-resolution browsers (I assume), but it may very
well be an issue with new functionality (especially if the text "Reached end of
page, continued from top" is present). This is just not an issue with a floating
dialog. Its size is 200 x 150 (or whatever) when it comes up, and it always
stays that size, regardless of how you resize your browser window. (This is one
of the drawbacks of the Google toolbar--if you have a search phrase with more
than one or two terms, they will disappear off the right side of the toolbar
(where you click them to find their occurrences on the page) on all but
high-resolution monitors with the browser maximized.) If there really is too
much functionality to fit into the basic size (200 x 150 or whatever), then
there can a button or checkbox that says "More/Less" or "Advanced" that expands
the size of the find dialog (MS Word currently does this). Indeed, all the
advanced find functionality in MS Word would just not be able to fit onto a
single-line (and perhaps even double-line) toolbar. It may not all be applicable
to a browser, but the point is that the toolbar is less flexible when it needs
to be expanded.

2. Actually, the IE find dialog is not modal (same for MS Word). You can
interact with the page while it's up. I would expect a find dialog to not be
modal, so I don't think this is a valid point.

3. I think this point is also based on the assumption that the find dialog is
modal. It isn't and shouldn't be. You can and should be able to select text from
the web page and paste it into the find dialog, or otherwise interact with the
current web page. (You can currently do that in IE and MS Word.)

I think the dialog is superior in the control it gives you. The toolbar forces
you to look/go to the bottom of the browser in order to see/type/click on
buttons. The dialog is flexible--it lets you put it where you want to put it--at
the bottom, on the side, even mostly off the monitor if you want. A
well-designed dialog could even, for example, move itself or scroll the page if
the next match would be under the dialog. (I thought the IE find did this but I
can't make it do so now. It's also annoying that it closes if you navigate away
from the current page, but a better find dialog could stay up while you
navigated pages or tabs.) Find has to scroll the page anyway if the next match
is out of the visible page, so this wouldn't be unexpected behavior.
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.