124989 - [RFE] find in input fields

Status: VERIFIED DUPLICATE of bug 58305

(SeaMonkey :: UI Design, enhancement)

Description

[Tim Coote]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8+)
Gecko/20020209
BuildID:    2002020908 (from header bar) (nb the id reported by user-agent in
bug entry form is 20020209)

Find (ctrl+f) does not seem to work properly in text entry fields.

For many uses this is not a problem, but where a browser is used to edit
information it's a pain. I found this while trying to set up TWiki as a
lightweight collaboration tool.

A twist on the reproduceability is that for twiki edit pages, where the text
input field is pre-populated, Mozilla appears to find *something*, but doesn't
highlight it. I'm guessing that it's finding it in the text input field.  This
doesn't work on this page as I couldn't use find to find the 1. in the text box
'Steps to Reproduce'



Reproducible: Always
Steps to Reproduce:
1.enter something in a text box on this page
2.use find to find what you've entered - doesn't work

more complete, slower and temporary example (may not work from outside my domain):
1. go to www.coote.org/twiki/bin/view, login guest, pw guest
2. Click on hyperlink Edit at the bottom of the page
3. use find to discover terms in the screen, eg twikiweb, or unique terms

Actual Results:  a- find doesn't find anything in input field
b- find button can be pressed 18 times for twikiweb, no item is highlighted (I
can find 17 copies the input file)

Expected Results:  each occurrence should be highlighted

Comment 1

[Peter Trudelle]

->enhancement/future

Comment 2

[Tim Coote]

I'm unclear on comment #1. Do you mean that it's an enhancement for the text to
be highlighted when it's found, or that it shouldn't be found in all parts of a
page in the first place ? (The code appears to exhibit both behaviours at the
moment).

I don't know where the spec. is or what's supposed to happen, but I doubt that
the first behaviour is correct. If my doubt is founded, then either the spec or
the code is wrong and needs to be fixed, not enhanced.

The second behaviour is less significant and explicable as a feature (easy fix
:-) ), but it *is* inconsistent to the user. I'd guess that it's down to what
'find' is looking at, which is what's delivered as the page, rather than what's
in the page after user interaction.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Akkana, don't you already have a bug on this?

Comment 4

[Peter Trudelle]

Highlighting is fundamental, but I've never seen this product search any
textfields or textareas, so that seems an enhancement.

Comment 5

[Akkana Peck]

Bug 120568 looks like the one, though bug 76374 is also relevant (I'm not
entirely clear what the difference is).

*** This bug has been marked as a duplicate of 120568 ***

Comment 6

[Tim Coote]

I don't believe that this is a duplicate of 120568. I think that 120568 only
refers to case 2 (ie cannot find text that has been entered into a textarea),
but not case 1 (does not highlight text found in a text area that comes from the
page served up by the web server).

Bug 76374 looks similar to case 2, but seems to be refering to the functionality
as used in a different part of mozilla

re comment #4 I agree for case 1, but not for case 2, as the text is already
being found (assuming that my analysis is correct ;-) and that the behaviour
isn't called for in the specification.

Can we assume that bug is only for case 2 now?

Comment 7

[Jesse Ruderman]

May be a dup of bug 58305, "Find in page ignores text fields".

Comment 8

[Asa Dotzler [:asa]]

*** This bug has been marked as a duplicate of 58305 ***

Comment 9

[sairuh (rarely reading bugmail)]

marking verified as a duplicate.

if you decide to reopen this bug, please clarify why.

search string for bugspam removal: SalviaGuaranitica