Closed Bug 258211 Opened 20 years ago Closed 17 years ago

Implement Find Toolbar

Categories

(Camino Graveyard :: Toolbars & Menus, enhancement)

Product:
Camino Graveyard
Component:
Toolbars & Menus
Platform:
PowerPC
macOS
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Camino1.6

People

(Reporter: tenbrook, Assigned: mikepinkerton)

References

Details

(Keywords: fixed1.8.1.12)

Attachments

(5 files, 2 obsolete files)

mockup of the UI
223.44 KB, image/png
Details
branch main menu nib
26.54 KB, application/zip
Details
take 2, changes from IRC
65.01 KB, patch
Details | Diff | Splinter Review
branch nib, part deux
6.85 KB, application/zip
Details
trunk patch
65.35 KB, patch
Details | Diff | Splinter Review 
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+.
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.


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.
(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.
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
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.
> there for I see no reason to implement this feature.

"Begin finding when you begin typing" - that's what I miss from Camino.
you have to hit "/" to activate find-as-you-type in camino.
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.
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
(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. ***
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.
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.
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.
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?
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.
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.
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.
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.
*** Bug 316694 has been marked as a duplicate of this bug. ***
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.
(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.
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.
(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.
Attached image 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.
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.
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.
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.)
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.
*** Bug 328042 has been marked as a duplicate of this bug. ***
I agree, the "highlight all occurrences" button is one of my favourite features of firefox.  I'd love to see this possible in Camino.
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. ***
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.
Assignee: mikepinkerton → nobody
QA Contact: toolbars
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.
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.
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.


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

(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.)
taking, i have patches.
Assignee: nobody → mikepinkerton
Target Milestone: Future → Camino1.6
Attached patch branch patch (obsolete) — — Splinter Review 

    
    

    
  

      
      
      
      

        Attached file
          
        nib for branch patch (obsolete)
        — 
      

    


  

    
    

    
  
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+

    
    

    
  


  

        Attachment #293211 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached file
          
        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

    
    

    
  
landed on branch, pulling trunk now, but might not be until tomorrow.
Status: NEW → ASSIGNED
Keywords: fixed1.8.1.12

    
    

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

    
  
Depends on: 408536

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: