157788 - [RFE] make Incremental find highlight all matches

Status: NEW

(SeaMonkey :: Find In Page, enhancement)

Description

[Josh Steiner]

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.

Comment 1

[Christopher Aillon (sabbatical, not receiving bugmail)]

->aaronl

Comment 2

[Aaron Leventhal]

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

Comment 3

[Aaron Leventhal]

Not taking.

Comment 4

[:deanis74]

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

Comment 5

[Ken Harris]

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.

Comment 6

[Johan Walles]

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.

Comment 7

[Arthur]

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.

Comment 8

[Aaron Leventhal]

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?)

Comment 9

[sairuh (rarely reading bugmail)]

-> fayt

Comment 10

[Jesse Ruderman]

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

Comment 11

[Robert Kaiser]

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

Comment 12

[David Bolter [:davidb] (NeedInfo me for attention)]

Mass un-assigning bugs assigned to Aaron.

Comment 14

[chAlx]

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.