as suggested in bug 30088 perhaps the incremental search feature should highlight all matches of the search on the page somewhat like VIM does, hopefully with a subtle color that does not detract from the readability of the page.

->aaronl

I'm not really into this at all - if someone wants to submit a patch I'll look at it.

Not taking.

This should probably have been resolved as invalid, but i'll verify it either way.

I'm puzzled. Is this "a bug which will never be fixed", or "not a bug"? They sound very different to me and I don't see how this is either one. Please elaborate.

I can't vouch for the original submitter, but what Emacs >= 21 does is that it highlights the current match just as you would expect. In addition to that, it also highlights all other visible matches in a less intrusive color. So for example, if you search for "foo", the first occurence of foo will be highlighted. Also, all other places on your screen saying "foo" will be highlighted as well (but in another color). When I first heard about this feature in Emacs21, I thought it sounded rather useless, but after experiencing it in practice I actually think it is very nice. For the record, I don't really understand why this bug has been marked WONTFIX.

Reopening bug as this is a valid request. Adding helpwanted keyword. This depends on bug 30088, it doesn't block it. Please leave this bug assigned to nobody as long as you don't want to implement this yourself.

Okay, I admit I didn't take this one seriously before. But perhaps I have seen the light. Maybe I'll have time to get a prototype working at some point. I think the large text that the Xerox browser used would be difficult for Gecko to overlay like that, and still be performant. From comment 91 in bug 30088, by Ken Harris > -- User chooses Edit->Find Interactively or presses cmd-shift-F (for example) > > -- A thin (1 text-line high, like the Personal Toolbar) search toolbar appears, > that says "Search this page for:" and has a text field, and focus is > transferred to the text field > > -- User types "modern" (for example) > > -- All occurrences of "modern" on the page are highlighted (google-cache-style) > and the first occurrence is selected. (These are updated after each keypress.) > In addition to highlighting, the words could get bigger, like Xerox PARC's > browser (http://www.parc.com/solutions/enhancedthumbnails/) > > -- To go to the next (or prior) occurrence of "modern", user chooses Edit-> > Find Again or presses cmd-G (maybe cmd-shift-G to search backwards). > > -- In addition to selecting the text, if that text is part of a link, that link > gets the dotted-outline-thingy, so pressing return/enter follows the link. > > -- When I'm done searching, I can choose Edit->Hide Interactive Find (same > menuitem, but its name has changed), or press cmd-shift-F (escape is taken, > right?), and the toolbar disappears. Focus is back on the web page, so I can > scroll with the up/down arrows. > > Come to think of it, up/down should still scroll the page when isearch is > being used. > > -- Since the bar is going to take up the whole width anyway, and nobody's > going to use all of it for their search text, you might want to put "Prior" > and "Next" buttons on the right side, with tooltips saying what their keyboard > shortcuts (e.g., "cmd-G") are, to make this more discoverable. > > Comments are more than welcome. (Is this more or less how it really works?)

-> fayt

See also bug 62467, same bug for normal find. I think this is a dup.

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

Mass un-assigning bugs assigned to Aaron.

OK, "Find in page" and "Find as You type" are now very similar. Bug 62467 and bug 97023 implementing mass highlight are resolved and FAYT now uses the same highlight settings as the last used "full" Find. Maybe it works not so good (no timeout, no option to turn highlight always on, ugly colors etc) but it works. Suggest to close as fixed.