User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:126.96.36.199) Gecko/20071025 Camino/1.5.3 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:188.8.131.52) Gecko/20071025 Camino/1.5.3 There are two issues with Find interface in Camino 1. if I search for a word that ISN'T in the web page, there is absolutely NO visual indicator that the word was not found. Only if I have my headphones on/sound enabled, there is a sound played. 2. When there are 1 or more occurrences of the word(s) they are highlighted. Problem is that, depending on the color of the page, it may be very hard to distinguish the highlighted words. Believe me, it took me up to 1-2 minutes to distinguish the word(s) in some pages. Reproducible: Always Steps to Reproduce: 1. Press Cmd+F 2. Type a search word and enter 3. Try to locate the highlighted word in the page Expected Results: Please do not reinvent the wheel ! Do what Safari 3 does. Their interface is the best. This is the only single thing that bothers me in Camino. So: 1. if the word(s) is not found, provide a CLEAR visual indication of this 2. if the words are found, do exactly like Safari 3. I understand that there is a special control in Leopard that does just that (dimming). The least you can do, is to change the highlight color dynamically, based on page background and text color.
See also bug 334586. Keep in mind that the highlighting is something controlled by core Gecko code and not (really) at all by the Camino front-end. Please only file one issue per bug in the future. I *think* there may have been a bug at one time about the lack of a visual indication for 0 find results, but the real problem here is that we play an alert sound that the user potentially doesn't hear. That's not the browser's fault; if you're going to have your volume on mute or not use headphones that are plugged in, there's nothing we *should* do other than what the OS already does for alert sounds while muted. If you feel strongly that there should be some visual indication when there are no results found, please file a *separate* bug on that, since this one is more about the highlighting (or lack thereof). (Keep in mind also that there are currently two totally different Find implementations used by Camino: the Find dialog and the inline find-as-you-type, both of which are largely controlled by core Gecko code.)
I strongly feel that a visual indicator should exist. I filled separate Bug 404945
I have to say, after using the new in-document Find implementation on 10.5 (which exists in both Safari 3 and TextEdit, at least) for a while, the old method of simply highlighting something does sort of suck, and hooking up Find to use the system highlight colour isn't going to improve that as much as I'd like it to. I have this sneaking suspicion that doing exactly what Safari 3 does is going to be really difficult, however, unless there's a new API for it somewhere. I do think we should make an effort to do it, though.
Not sure how Safari's doing it, but bug 258211 comment 42 mentions text apps use showFindIndicatorForRange: in NSTextView, which would do us a hill of beans of good :P
This is going to need some sort of Core support to do in Gecko (since we can't use NSTextView's stuff); not sure if it needs to go to Find Backend or Widget:Cocoa, or where.
Component: General → Find Backend
Product: Camino → Core
QA Contact: general → find-backend
Summary: Found items (as result of Find command) are hard to distinguish in the page → Imitate Safari's Find results highlighting behavior
Why can't you replicate what Safari does (looks like "dim the page and highlight the word") without additional core stuff? If you can't, what additional core stuff do you need, exactly?
Maybe we can, though at the moment no one is sure how we'd go about manipulating the page opacity (and the selection highlight, which is rounded and yellow and larger than a normal highlight).
Oh please implement this. This would be wonderful! Sometimes when there is a lot of text on a page I do find it difficult to see what find highlighted and so I click next and previous until I do see it. Please implement this.
This bug seems to be a duplicate of this bug here: 384458
Since per bug 384458 comment 2 Safari implements this manually and there doesn't seem to be any specific support for this from Cocoa on Mac, this is indeed a dupe of bug 384458. (showFindIndicatorForRange is specific to NSTextView, and NSTextFinder, which can highlight matches, seems too specific for our case.)
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 384458
You need to log in before you can comment on or make changes to this bug.