Implement Find Toolbar

RESOLVED FIXED in Camino1.6

Status

Camino Graveyard
Toolbars & Menus
--
enhancement
RESOLVED FIXED
14 years ago
11 years ago

People

(Reporter: Warren TenBrook, Assigned: Mike Pinkerton (not reading bugmail))

Tracking

({fixed1.8.1.12})

unspecified
Camino1.6
PowerPC
Mac OS X
fixed1.8.1.12
Dependency tree / graph

Details

Attachments

(5 attachments, 2 obsolete attachments)

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a3) Gecko/20040905 Camino/0.8+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a3) Gecko/20040905 Camino/0.8+

Implement the find dialog as a toolbar in Camino, reproducing the Find Toolbar
feature in Firefox.  I'm sold on this feature as it allows the find function to
be readily available in a reproducible location without obscuring content.

Reproducible: Always
Steps to Reproduce:
1.  Select Edit...Find in Page...

Actual Results:  
Floating dialog appears that obscures content, depending on location of dialog
and how the page is scrolled.

Expected Results:  
Find Toolbar appears (either below bookmark bar, or above status bar, it matters
not) with interface similar to Firefox 0.9+.

Comment 1

14 years ago
It appears that you are not aware of the "Find As you Type" feature in all
Mozilla  browsers. In Camino when ever you are viewing a page hit the "/"
forward slahsh key and type the word you are looking for. You will see that FF
and Camino will immdedialt start searcing fro it and will highlight the found word.

there for I see no reason to implement this feature.

(Reporter)

Comment 2

14 years ago
Yes, I am aware of type ahead find; Firefox uses type ahead find as well, but
now  a toolbar appears whenever "/" is selected, exposing the find feature in a
more friendly and discoverable way.  It seems like excellent GUI that would
alleviate the obscurity of find-as-you-type.

Comment 3

14 years ago
(In reply to comment #2)
>  It seems like excellent GUI that would
> alleviate the obscurity of find-as-you-type.

But at the present Firefox, since FAYT of exclusive use is mounted, the problem
has occurred in the environment using IME.
(It is very hard to use.)

When it mounts this function, the same problem as Firefox is wanted not to occur.

Comment 4

14 years ago
I'm confirming as I do think that giving the user a more exesibel way to use
find as you type oposed to the regular find in page panel is better. Putting it
in our search filed should also put it in a place people expect to find it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Future

Comment 5

14 years ago
When I switched from Firefox to Camino, this was the one feature that I felt was
sorely lacking. The floating find panel is a difficult UI to maneuver, and to
reuse on additional pages, as well as the lack of feedback including turning red
when the partial word cannot be found. Please highly consider implementing this
into Camino.
(In reply to comment #4)
> I'm confirming as I do think that giving the user a more exesibel way to use
> find as you type oposed to the regular find in page panel is better. Putting it
> in our search filed should also put it in a place people expect to find it.

Would there be a way to implement this more innovatively (yes, I made that word up).

For example, what if when a user uses FAYT the text they're searching for
appears in the search bar? An icon would need to be created and placed
effectively to somehow indicate the search was within the page, but maybe simple
controls (next, previous, cancel) could be implemented while still allowing the
user to use the drop down search button to conduct a regular internet search.
(In reply to comment #4)
> I'm confirming as I do think that giving the user a more exesibel way to use
> find as you type oposed to the regular find in page panel is better. Putting it
> in our search filed should also put it in a place people expect to find it.

Would there be a way to implement this more innovatively (yes, I made that word up).

For example, what if when a user uses FAYT the text they're searching for
appears in the search bar? An icon would need to be created and placed
effectively to somehow indicate the search was within the page, but maybe simple
controls (next, previous, cancel) could be implemented while still allowing the
user to use the drop down search button to conduct a regular internet search.

Comment 8

13 years ago
> there for I see no reason to implement this feature.

"Begin finding when you begin typing" - that's what I miss from Camino.
(Assignee)

Comment 9

13 years ago
you have to hit "/" to activate find-as-you-type in camino.

Comment 10

13 years ago
This isn't the same as find as you type, since find as you type doesn't allow
for spaces, and doesn't have an intuitive UI. Check out Firefox for the specifics.
(Assignee)

Comment 11

13 years ago
not allowing spaces is a bug (filed elsewhere). i'm not saying find toolbar
isn't a valid bug, you just stated that you missed "begin find when you begin
typing". we'll probably never do that in camino. too many people complained when
we had that turned on initially.
And actually, you set Find As You Type in Camino to start without the /. It's a
hidden preference. See here:
http://www.caminobrowser.org/support/sup_hiddenprefs.html

Comment 13

13 years ago
(In reply to comment #12)
> It's a hidden preference.

That's what I was looking for! Thanks, Samuel!
Actually, it would be great to have a checkbox for this in 'Web Features' (it
must not be turned on by default).
*** Bug 296297 has been marked as a duplicate of this bug. ***

Comment 15

13 years ago
This feature would really be appreciated. I'm still with firefox because and
couldn't find a so well implemented and user-friendly search box. Please
consider implementing this. Firefox did it right! Thank you.

Comment 16

13 years ago
This is the number one thing keeping me from using Camino instead of Firefox.
There are a number of reasons to use Command+F over Find-As-You type (noteably
having the last search saved for re-use) and the current pop-up interface is
much more obstrusive than the way Firefox does it. I thought it was silly in
Firefox at first too, since it not only breaks OS X's interface conventions but
also those of every other OS, but it's so much easier to use that this
disadvantage becomes negligible. With a pop-up, I'm constantly moving the window
around because it overlaps found words and in Firefox I don't have to do that. I
never miss a found word in Firefox.
(Assignee)

Comment 17

13 years ago
find-as-you-type saves the find string. if you open the find window, you see it.
also, if you switch to another app that supports the find pasteboard, it's there
too.

i don't follow.

Comment 18

13 years ago
An earlier reply said that the Find bar wasn't needed since FAYT was in place. 
If FAYT is so great and all-encompassing, then why implement the current Find
popup window?

What you're hearing people say (and what I came here originally to say) is, sure
FAYT is nice, but if you're going to have an additional UI for Find, a bar
similar to the one in Firefox is preferred to the popup window.

I mean, come on.  IE has a popup window for Find.  Are you saying you can't do
better than that, or that you won't?

Comment 19

13 years ago
There are two concerns I have with doing a find bar just like Firefox.

1) All OSX native applicatiosn have a find window as we have it now. So removing
it would in essence break user expectancy, which is a bad thing IMHO. But I
agree that what we have now is not half as good as we could make it.

2) We have a very good excisting tool object we could reuse for searching on a
page and that is the Search toolbar item. I'd imagine and item added to the list
called "Search on Page" passing the pressed keys to FAYT higlighting them on the
page.

I'd think a combination between the find panel and search field using FAYT would
be the way to go for camino.

Comment 20

13 years ago
Furthermore, just because one feature is great (Find As Your Type), that should
not prevent other related features (the Edit -> Find In Page menu options) from
being improved. It would be one thing if the Find In Page option was being
removed, but since it isn't then I think it could be made a lot better (taking
Firefox's example...). I'd image a lot more people use Find In Page than they
use FAYT, considering that FAYT is more of a shortcut you have to know how to
activate (by pressing /...) rather than a feature accessible by the interface.

Comment 21

13 years ago
The easiest way for us to make something that works with what we have is: (I think)
-Kill the find panel, and move the two options to check items in a  View -> Find
Options submenu
-Make Cmd-F move you to the search toolbar field, or bring up the old panel if
the search field is not on the toolbar
-Make "Search this page" an option in the search field, and make sure the field
remembers selection across searches/windows/sessions
-Always run incremental search? We could do this only on FAYT activation, or
leave it as a preference, too.

Comment 22

13 years ago
As another convert from Firefox to Camino I'd like to add more support for doing a Firefox-style find bar.  That really is something that Firefox nailed.  The key things I think are good about it:

- Doesn't obscure the page
- Is attached to the window you are searching
- Gives visual feedback when your partial search is not matched
- Uses an editable text area (unlike FAYT) so you can modify your search

The ideas in #21 would mostly work for me, except that I don't use the Search toolbar field, so I would still be stuck with a find pop-up that floats separately from the page I would be searching.

Comment 23

13 years ago
*** Bug 316694 has been marked as a duplicate of this bug. ***

Comment 24

13 years ago
I agree with previous speakers. To sum up: the current "Find in Page" dialog box probably adheres to the Mac OS X UI guidelines, but it is very limited and suboptimal for a web browser. 

Therefore I think implementing something similar to (though more "native") version of the search bar in Firefox would be justified.

Comment 25

13 years ago
(In reply to comment #21)
I agree with comment 21 and 22 but why not have an option for both? People who want it to conform to Mac OS X guidelines can keep their search box and everyone else who prefers the Firefox system (including me) would be able to use that.

One of the things I like about camino is that most of the things that need extensions in Firefox are built into Camino (and its faster too) but the find-toolbar is one of Firefox's better features IMHO but hey as people seem to be disagreeing both seems like the most sensible option.

Comment 26

13 years ago
Here's an idea:  we could re-use the search textfield (currently used only for searching on Google) for searching on the same page.

So if you'd type Ctrl+F that textfield could get focus and perhaps some additional buttons/checkboxes (for things such as "Wrap around", "Ignore case") would slide in next to it.

Don't know if this is a bad or good idea. :-)

Otherwise, a simple sheet could slide down, similar to Firefox but more mac-savvy.

Comment 27

13 years ago
(In reply to comment #26)
> Otherwise, a simple sheet could slide down, similar to Firefox but more
> mac-savvy.

It might be a bit odd to have options appear in the search field. But as I listed above I do think it would be a good idea to add a "Search in Page" item in teh search field to trigger any other implementation we might make.

- I'm not against doing it the way FF does it, but I do think that UI wise it takes a lot of vertical and horizontal space.
- Since all Mac OS X apps have a find panel, I'm still very much for making ours work with FAYT. I imagine this would be the find panel with a round search field. As soon as one would type a word it would show the found text in the page highlighted just as we see it in FAYT. This would then also accomodate the FAYT options. Choosing "Search in Page" from the main toolbar and typing a word would then also open the find in page panel and reveal the options.

Comment 28

13 years ago
Created attachment 208550 [details]
mockup of the UI

I do think that we also should keep the current minimal implemetation. I would not like to be confronted with the search panel or any UI everytime.

Comment 29

13 years ago
The dialog is a bad idea because it hides part of the very page you're searching in - this is why firefox uses the toolbar, and why I was thinking of a sheet.

The sheet would be very slim though, because it only has to contain a search field and maybe one or two checkboxes arranged horizontally - so it could be made to look very clean and uncluttered.

Comment 30

13 years ago
OK fair enough, but a sheet will take away the focus from the page, that's not what we want either. We want people to be able to scroll and select stuff while they search. That's why the UI from firfox is not that bad.

Comment 31

13 years ago
Why not have a search bar, as in the bookmarks page, but with highlight, find next/previous, and match case as in firefox. I agree the firefox setup uses space but the only place to reduce this is to put the search would be in the status bar (though the status bar would need to be a little thicker to be easy to see and use the search.)

Comment 32

13 years ago
Another reason that I use Firefox FAYT toolbar is "highlight" button. It's pretty nice to see how many keyword you enter in that page, which not in current Camino's Find Dialog.

Comment 33

13 years ago
*** Bug 328042 has been marked as a duplicate of this bug. ***

Comment 34

12 years ago
I agree, the "highlight all occurrences" button is one of my favourite features of firefox.  I'd love to see this possible in Camino.

Comment 35

12 years ago
Why not implement Google Toolbar style highlighting, instead?

With Google Toolbar for Firefox and WinIE, it's possible to press a button to highlight all the search terms you entered in the search box. Each search term then gets highlighted in different colors. I think this is _a lot_ faster and more practical than "Find In Page" or "Find As You Type".

There is a bookmarklet that mostly does the same:
http://www.gizmometer.com/blog/?p=14
*** Bug 345484 has been marked as a duplicate of this bug. ***

Comment 38

11 years ago
I fully support incorporating a FF style find feature. It's so disruptive to have a separate window pop open to find content on the page.

The "/" and start typing feature is nice, but not intuitive.

Updated

11 years ago
Assignee: mikepinkerton → nobody
QA Contact: toolbars

Comment 39

11 years ago
Safari 3.0 is going to have a great implementation for this with its "Lightbox" feature. Instead of highlighting search terms in light, hard-to-see blue, Camino should dim the page while leaving the search term (in a toolbar with search-as-you-type) undimmed.

I also recommend the find toolbar to be at the bottom since with tabs, bookmarks and the URL bar the top is cluttered enough.

Comment 40

11 years ago
Jasper, UI consistency is a good thing, but the current Find implementation in OS X is legacy and sticking to it might be a bad idea.
Firefox introduces an excellent solution and Safari 3 extends it further in its inline search implementation.
By highlighting the selected text user gets a clear visual clue of where the searched elements are located (similar logic is excellently implemented in EMEditor) and navigation is way easier this way.
Classical Find has some serious disadvantages:
* It's a separate window (in some implementations it messes with Expose)
* It covers the information by itself as it's too large
* It provides little visual feedback to the page as you don't get the idea about how many results are found and if they're ever found before making a set of operations.
Modes kill, remember? ;)

You don't even need to re-invent the wheel as there're already good implementations of the model. I do also think that top bar is a better place for such search, i.e using a Safari-way.

P.S.: I do know about FAYT and personally see a very little practical use of it.

Comment 41

11 years ago
Please DO NOT reinvent the wheel. Take inspiration from the BEST interface , the one in Safari 3 ("lightbox").

There are 2 problems with current interface 9as described in Bug 404515):

1. there is no visual indication that the word is not found
2. depending on the page colors, the highlighted words may be very hard to distinguish.

Comment 42

11 years ago
Leopard now has the "lightbox" find feature accessible to developers via showFindIndicatorForRange: in NSTextView. This would make this feature Leopard only, but many programs are taking advantage of the unique tools available in Leopard and dropping support for earlier versions. I suppose this is something for 2.0, so support for 1.x can remain while 2.0 is Leopard-only, no?

http://mattgemmell.com/2007/10/28/get-rid-of-your-code-with-leopard

Comment 43

11 years ago
(In reply to comment #41)
> 1. there is no visual indication that the word is not found
> 2. depending on the page colors, the highlighted words may be very hard to
> distinguish.

Neither of those have anything to do with this bug; please don't confuse bugs by trying to conflate the discussion. This bug is specifically about moving the interface to triggering a search from a panel into an in-page bar. It has nothing to do with the behavior of highlighting, so this is not the place to discuss that. (The fact that Safari happened to change the highlighting at the same time that they changed the location of the user controls does not make them the same issue.)
(Assignee)

Comment 44

11 years ago
taking, i have patches.
Assignee: nobody → mikepinkerton
Target Milestone: Future → Camino1.6
(Assignee)

Comment 46

11 years ago
Created attachment 293213 [details]
nib for branch patch
(Assignee)

Comment 47

11 years ago
Created attachment 293214 [details]
branch main menu nib

Comment 48

11 years ago
Comment on attachment 293211 [details] [diff] [review]
branch patch

r=me with fixes from IRC, and with follow-up bugs filed for:
- Trying to fix the fact that incremental search should start again from the beginning of the current range, rather than skipping to the next word
- Fixing the visual appearance of the bar (background, spacing, etc.)
Attachment #293211 - Flags: review+
(Assignee)

Comment 49

11 years ago
Created attachment 293221 [details] [diff] [review]
take 2, changes from IRC
Attachment #293211 - Attachment is obsolete: true
(Assignee)

Comment 50

11 years ago
Created attachment 293222 [details]
branch nib, part deux
Attachment #293213 - Attachment is obsolete: true
Attachment #293221 - Attachment is patch: true
Attachment #293221 - Attachment mime type: application/octet-stream → text/plain
(Assignee)

Comment 51

11 years ago
landed on branch, pulling trunk now, but might not be until tomorrow.
Status: NEW → ASSIGNED
(Assignee)

Updated

11 years ago
Keywords: fixed1.8.1.12
(Assignee)

Comment 53

11 years ago
fixed on trunk. please open new bugs for additional functionality requests.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED

Updated

11 years ago
Depends on: 408536
You need to log in before you can comment on or make changes to this bug.