452001 - Use new search textbox widget in the Find Toolbar

Status: RESOLVED WONTFIX

(Toolkit :: Find Toolbar, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1a2pre) Gecko/20080821020645 Minefield/3.1a2pre ID:20080821020645

As mentioned in bug 388811 comment 0 the textbox in the Find Toolbar should make use of the new search widget. How can we handle the current behavior (red background, and sound) if no results were found?

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

This should also handle the textbox on the quick search toolbar.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Steffen, any interest on this bug?

Comment 3

[Dão Gottwald [:dao]]

Bug 388811 comment 0 says "without the [...] clear button". We don't want Esc to clear the field either. So what exactly should the find toolbar inherit from the search binding?

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

mconnor could you please describe what you have meant in bug 388811 comment 0:

> anywhere else that has a search/filter/find function (find toolbar,, without
> the greytext/clear button would still be able to use it)

I just created a new bug to not miss any possible instance which could make use of the search widget.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Why this bug should be INCOMPLETE? Read the status description and you will see that it's wrong. I (as reporter) gave enough comments on that bug. We still miss the answer of mconnor. It should be easy for you to ping him instead of closing a bug as INCOMPLETE.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Tony, do you see a chance that I can get an answer from mconnor to the status of this bug?

Comment 7

[Mike Connor [:mconnor]]

I think I originally intended it to be a normal textbox that just looked like a native search widget, but it turned into a much more useful idea, but one that probably isn't useful in find toolbar anymore.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #7)
> I think I originally intended it to be a normal textbox that just looked like a
> native search widget, but it turned into a much more useful idea, but one that
> probably isn't useful in find toolbar anymore.

Alex, what is your opinion? With this search field we start searching immediately while typing. In that way it differs from all the other instances, e.g. within the library, about:config, and others. Should all of them have the same behavior? The current implementation makes it even hard to delete entered text. Pressing Esc to get rid of the given input seems more reasonable as closing the find toolbar.

Marco, what is your opinion from the a11y side?

Comment 9

[Marco Zehe (:MarcoZ)]

First, IIRC, the different behavior (start searching immediately versus start searching when pressing ENTER) is intentional: In things such as the Add-Ons manager, a search as you type would immediately connect to the internet with the first press of a letter, which may be undesirable. However, for the Find toolbar, this is very useful and efficient and is being used by lots of people searching web pages for terms they're familiar with, using the screen reader to immediately give them feedback if the search term was found.

Second, as for pressing Escape: First clearing the search term, then if there is no such term, closing the dialog, as is done in Add-Ons Manager, for example, should be the case here as well if the Search widget is implemented.

Comment 10

[Alex Faaborg [:faaborg] (Firefox UX)]

>Alex, what is your opinion? With this search field we start searching
>immediately while typing.

We definitely should search once the user starts typing.  We should also use the search field to get the functionality of the close icon that clears the contents.

The platforms seem to differ on if a field with that type of behavior should have a magnifying glass icon in it or not.

On Vista the magnifying glass icon does show up in fields that search immediately, while on OS X these fields sometimes have a magnifying glass, and sometimes don't.

Currently we are displaying the magnifying glass in other areas of our UI that search immediately (like the download manager, or even the find bar on OS X).

I'm pretty indifferent either way about the magnifying glass
-it makes the field more descriptive, but on the down side it is visually a little more complicated, and the user may also move their hand to the mouse to click on it, when they didn't actually need to.

Comment 11

[Alex Faaborg [:faaborg] (Firefox UX)]

talking to whimboo on irc:  if losing the red background is the only reason we can't change to the search bar, I think it is worthwhile to pick up the close box, since we say "phrase not found" and the color of red isn't even a platform specific color to begin with.  We can go back and fix this correctly for each platform later.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #10)
> On Vista the magnifying glass icon does show up in fields that search
> immediately, while on OS X these fields sometimes have a magnifying glass, and
> sometimes don't.

Alex, this was an issue on OS X but was fixed by bug 450800. Now, we always show the magnifying glass on the left side. The only exception is for the search field. There the icon is still placed on the right side due to the engine selection dropdown. 

Dao, can you please catch-up with the latest comments? Is it worth to base the findbar-textbox on the searchbox instead on the normal textbox?

Comment 13

[Dão Gottwald [:dao]]

(In reply to comment #12)
> Is it worth to base the
> findbar-textbox on the searchbox instead on the normal textbox?

The findbar textbox doesn't implement anything that could be inherited from the search textbox, so no.

(In reply to comment #9)
> as for pressing Escape: First clearing the search term, then if there
> is no such term, closing the dialog, [...] for
> example, should be the case here as well if the Search widget is implemented.

I don't understand the "then if there is no such term" part. Anyway, do we have a reason to believe that the user is more likely to enter another term than to close the findbar?

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #13)
> > findbar-textbox on the searchbox instead on the normal textbox?
> 
> The findbar textbox doesn't implement anything that could be inherited from the
> search textbox, so no.

So what about the magnifying glass? Where does it come from? Further we could have a close icon which is brought by the searchbox. 

> I don't understand the "then if there is no such term" part. Anyway, do we 

Same behavior as we have in other search fields. Blur the textbox only if no value is set.

> a reason to believe that the user is more likely to enter another term than to
> close the findbar?

That's a good question. Personally I'm still humbled when doing multiple searches. The entered text isn't highlighted and you have to delete each letter step by step or via Cmd/Ctrl+A and a followed Delete. Probably we don't have to reset the search term but a close button would be handy. Safari does it the same way. And having this elements would feel more platform native. I'll attach a screenshot.

Alex, what do you think?

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: Findbar of Safari

Comment 16

[Dão Gottwald [:dao]]

(In reply to comment #14)
> (In reply to comment #13)
> > > findbar-textbox on the searchbox instead on the normal textbox?
> > 
> > The findbar textbox doesn't implement anything that could be inherited from the
> > search textbox, so no.
> 
> So what about the magnifying glass? Where does it come from? Further we could
> have a close icon which is brought by the searchbox.

The search glass is a matter of styling, doesn't need the search textbox binding.

> > a reason to believe that the user is more likely to enter another term than to
> > close the findbar?
> 
> That's a good question. Personally I'm still humbled when doing multiple
> searches. The entered text isn't highlighted and you have to delete each letter
> step by step or via Cmd/Ctrl+A and a followed Delete.

Or just Ctrl+A and start typing.

Comment 17

[Alex Faaborg [:faaborg] (Firefox UX)]

Dao's description of the esc behavior matches how we use esc elsewhere in the product (with the download manager having bug 438765 to make it consistent).

In terms of the close button, this is standard for search fields on both OS X and Vista, and XP doesn't really have anything to base the design of search fields on, so I think it makes sense to deploy the close button on all platforms.  Is there a good reason not to add the close button to the search box?

Comment 18

[Dão Gottwald [:dao]]

A clear button in the input box next to the close button for the find bar doesn't seem ideal, especially if they are styled similarly. Moreover I think that, since the find bar is keyboard-driven and unless we change the behavior of Esc, a clear button that's only mouse-accessible feels odd.

Comment 19

[Mike de Boer [:mikedeboer]]

There are no plans to (re-)use the search input inside the findbar in the near future.
I think that in the time between filing of this bug and today, the overlap between the two search inputs has diverged as well - because it depends much on the placement of the control.
One thing that the search input does have is autocomplete, which the findbar would ultimately use for an MRU list.