it'd be cool if we could give preference for matches at start of word (ie, per-word basis), rather than matching strings within the word. implementing this would depend on bug 14871.

I don't think this depends on bug 14871. Bug 14871 is about the "Find in page" function, while this is about "Find as you type". And I'm very much in favour of this suggestion. I'd even vote to broaden the scope of this bug and introduce a "precedence" system in which links that are more relevant to the text typed are found first: - Give top precendence to links that match the entire text typed. (For example, if there is a link whose text is just one letter, pressing that latter would get you to the link, rather than some other link that just happens to contain the same letter.) - Second precedence to links in which the first word(!) is the text typed. - Third precedence to links in which an entire word is the text typed. - Fourth precedence to links that begin with the text typed. - Fifth and last precedence to links that contain the text typed. Of course, F3 and Ctrl+G should just find the next occurrence of the text typed and ignore the precedences, otherwise this would get too complex and confusing.

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.

See also bug 269442 for the Firefox version of it which is WONTFIX at the moment.

Sounds like extension fodder. There are several findbar extensions that do regexp eg. /Find Bar/ https://addons.mozilla.org/en-US/firefox/addon/99836/

(In reply to comment #5) > Sounds like extension fodder. Well... not really. Extensions are forced to re-implement the entire search functionality, because they can't extend the existing nsFind class. They invariably end up missing very important bits, like, for example, /Find Bar/, which can't search in text areas. They also won't benefit from any future bugfixes in the core searching code. Why not extend the core search with the whole words ability, without exposing it in the UI by default? Then an addon can add the necessary UI easily and properly.

> Why not extend the core search with the whole words ability, without exposing > it in the UI by default? Then an addon can add the necessary UI easily and > properly In that case please file a bug in the appropriate location e.g: Product: Toolkit Component: Find Toolbar. If they fix it in core we will automatically pick it up.