Note: There are a few cases of duplicates in user autocompletion which are being worked on.

allow FAYT to search on a per-word basis

RESOLVED WONTFIX

Status

SeaMonkey
Find In Page
--
enhancement
RESOLVED WONTFIX
15 years ago
7 years ago

People

(Reporter: sairuh (rarely reading bugmail), Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
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.

Comment 1

14 years ago
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.
(Assignee)

Updated

9 years ago
Product: Core → SeaMonkey

Comment 2

8 years ago
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
Status: NEW → UNCONFIRMED
Mass un-assigning bugs assigned to Aaron.
Assignee: aaronleventhal → nobody

Updated

7 years ago
No longer depends on: 14871
Depends on: 14871
See also bug 269442 for the Firefox version of it which is WONTFIX at the moment.
See Also: → bug 269442
Whiteboard: [CLOSEME INVA/WONT?]

Comment 5

7 years ago
Sounds like extension fodder. There are several findbar extensions that do regexp eg. /Find Bar/
https://addons.mozilla.org/en-US/firefox/addon/99836/
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Depends on: 269442
No longer depends on: 14871
Resolution: --- → WONTFIX

Comment 6

7 years ago
(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.

Comment 7

7 years ago
> 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.

Updated

7 years ago
Keywords: helpwanted
Whiteboard: [CLOSEME INVA/WONT?]
You need to log in before you can comment on or make changes to this bug.