Find toolbar fails to un-highlight matching text in user-input fields

RESOLVED FIXED

Status

()

Toolkit
Find Toolbar
RESOLVED FIXED
14 years ago
10 years ago

People

(Reporter: Petey, Assigned: Blake Ross)

Tracking

({fixed-aviary1.0})

unspecified
x86
All
fixed-aviary1.0
Points:
---
Bug Flags:
blocking-aviary1.0 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: ETA is 10/15 [have patch] bryner)

Attachments

(2 attachments)

(Reporter)

Description

14 years ago
Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040707
Firefox/0.9.0+

When I type a string into the new "Find Bar" which matches something in a
user-input field and then click "Highlight", the text in the field is
highlighted normally.  However, when I click "Highlight" again (to un-highlight
the text) the text in the field remains highlighted.  Furthermore, the
highlighted text in the field cannot be partially selected (you cannot select
parts of the string), only wholly selected by dragging the cursor across the
entire string.

To recreate this bug:  Type something in the "Additional Comments:" field above
which is also in the regular text of the page ("bugzilla" for example) and then
type it into the find bar and click "Highlight" twice.  Notice how the regular
text was highlighted and un-highlighted properly but the field-text stays
highlighted.  Also observe the unusual selection behavior (in order to select
the text at all, you must also have text on either side of the highlighted string).
(Reporter)

Updated

14 years ago
Summary: New "Find Bar" fails to un-highlight matching text in user-input fields → Find toolbar fails to un-highlight matching text in user-input fields
-> Find Toolbar component.
Component: General → Find Toolbar / FastFind

Comment 2

14 years ago
The un-highlighting problem only happens when the text in the user-input field
is the *only* result found by Find. The selection problem, however, is the same.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040715
Firefox/0.9.1+

Comment 3

14 years ago
(In reply to comment #2)
> The un-highlighting problem only happens when the text in the user-input field
> is the *only* result found by Find. The selection problem, however, is the same.
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040715
> Firefox/0.9.1+

Hrm, not here (unless I'm understanding you wrong--do you mean its only if it
appears once in the page and once in the text-box? Thats how I just saw it)

Here is what I did:
1)At a site (not sure which one, doesn't matter), I hit / to bring up the
toolbar, and then searched for "SATA" (no quotes), which turned up no results. I
hit the highlight button
2)I continued navigation as normal for a little
3)Making a post at the mozillazine forums, it contained "SATA", and when I
previewed the post, the text SATA was highlighted, both in the preview area of
the page, and the text box.
4)I hit / to bring up the Find toolbar (focus on the page, not the text-box),
hit the highlight button
5)Text in the preview area was unhighlighted, the text area "SATA" remains
highlighted

Setting OS -> ALL
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040725 Firefox/0.9.1+
OS: Windows XP → All

Comment 4

14 years ago
Furthermore, it seems that, in addition to it failing to highlight (I can
confirm this in the latest nightlies), it doesn't offer any indication that it
has searched  (or, more properly, that it has _found_) the term in the first place.

The old find function would select the found string in the same way you would
select it with your mouse/keyboard, and you would be instantly able to edit the
term.  While the new find bar does scroll through the textarea indicating that
it has done something, it does not highlight the term, or, more ideally, select
it for editing.

For someone who works with web-based content editors frequently, it leaves me
crying for the old find function again ;-)

Updated

14 years ago
Flags: blocking-aviary1.0?

Comment 5

14 years ago
*** Bug 254713 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

14 years ago
Flags: blocking-aviary1.0? → blocking-aviary1.0+

Comment 6

14 years ago
*** Bug 259986 has been marked as a duplicate of this bug. ***

Comment 7

14 years ago
1. after changing search string, highlighting of edit fields is not updated

2. it is impossible to move the cursor through highlighted (yellow) part of edit
fields 

Reproducible: Always
Steps to Reproduce:
In Firefox 1.0 ...

1. open (for example) http://www.google.de/
2. enter (for example) "firefox browser" and confirm to search
3. press CTRL+f
4. enter "firefox browser" into the search bar
5. enable "Highlight"
6. delete the " browser" in the search bar, so that there only is "firefox"

Now the word "browser" is kept higlighted in the search fields (while in the
page content correctly only "firefox" is higlighted).

- try to edit the higlighted part of the edit field. it is impossible to set the
cursor into the yellow part!


(if the whole text is yellow it is difficult to get the cursor right beside the
text. If you select all via the context menu and then press arrow-right the
cursor is right beside the text.)


Expected Results:  
1. highlighting of edit fields should be updated correctly

2. it should be possible to move the cursor through higlighted parts of edit fields

Comment 8

14 years ago
If you try to drag&drop a part of text into the yellow part of a edit field, the
text vanishes!

Comment 9

14 years ago
Find has an incosistent behavior:

1. Go to https://bugzilla.mozilla.org/show_bug.cgi?id=259685
2. CTRL+F
3. type bugs
4. Click Highlight: bugs higlighted, as expected.
5. Click Highlight again

bugs in QA Contact (firefox.form-manager@bugs) and in Reassign textboxes
(bugs@bengoodger.com) remains highlighted. (It remains highlighted when the Find
string is changed to bug instead of bugs.)

Start again.

1. Go to https://bugzilla.mozilla.org/show_bug.cgi?id=259685
2. CTRL+F
3. type bugs

bugs found at Assigned to Ben Goodger <bugs@bengoodger.com>

Click Find Next

No more occurences found, reeached end of page. The occurences which were
highlighted previously are not found now.

Also, when the word "bugs" in the textbox is highlighted, it becomes impossible
to select the full string in the textbox. You can select either
"firefox.form-manager@" or "@bugs", but not the full string. 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040920
Firefox/0.10

Comment 10

14 years ago
Highlighted Text from Find bar stays hightlighted after
closing the find bar and leaving the page.

Steps to reproduce:
Open a page (Any page even this forum page)
Click CTRL-F to open the find bar.
Type in some text that can be found on the page.
Click the highlight button on the find bar to see all instances of the word you
typed highlighted. (Cool feature love it!)
Close the find bar
Navigate away from the page and notice that word will still be hightlighted on
any other page you visit if it exists on the page.
Also navigate back to the original page and see the word highlighted there also. 

Comment 11

14 years ago
Find has an incosistent behavior:

1. Go to https://bugzilla.mozilla.org/show_bug.cgi?id=259685
2. CTRL+F
3. type bugs
4. Click Highlight: bugs higlighted, as expected.
5. Click Highlight again

bugs in QA Contact (firefox.form-manager@bugs) and in Reassign textboxes
(bugs@bengoodger.com) remains highlighted. (It remains highlighted when the Find
string is changed to bug instead of bugs.)

Start again.

1. Go to https://bugzilla.mozilla.org/show_bug.cgi?id=259685
2. CTRL+F
3. type bugs

bugs found at Assigned to Ben Goodger <bugs@bengoodger.com>

Click Find Next

No more occurences found, reeached end of page. The occurences which were
highlighted previously are not found now.

Also, when the word "bugs" in the textbox is highlighted, it becomes impossible
to select the full string in the textbox. You can select either
"firefox.form-manager@" or "@bugs", but not the full string. 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040920
Firefox/0.10

Comment 12

14 years ago
Comment #11 duplicate of comment #9 as a result of mid-air collision (?!)

Comment 13

14 years ago
Another problem with highlighting and textboxes: bug 256989.

Updated

14 years ago
Whiteboard: ETA is 10/17
Whiteboard: ETA is 10/17 → ETA is 10/15

Comment 14

14 years ago
Created attachment 161961 [details] [diff] [review]
don't highlight text within INPUT or TEXTAREA 

Don't highlight text within input or textarea elements. Also makes highlighted
text consistent with Find Next function.

Updated

14 years ago
Attachment #161961 - Flags: review?(bryner)

Updated

14 years ago
Whiteboard: ETA is 10/15 → ETA is 10/15 [have patch] bryner
Created attachment 162249 [details] [diff] [review]
alternate fix

This patch makes unhighlighting in input/textarea work correctly.  The problem
is that nsIFind::Find() will search the anonymous content inside of these
elements, and that's not accessible via document.getElementById().  So, this
patch tracks the last highlight string and searches on it again when we want to
remove highlighting.
Attachment #162249 - Flags: review?(firefox)

Comment 16

14 years ago
(In reply to comment #15)
> Created an attachment (id=162249)
> alternate fix
> 
Brian,

Since you are moving the code that sets the highlight style, could you also
change the style to the following:

baseNode.setAttribute("style", "background-color: " + color + "; color: #000000;");

This solves the problem of light text not being visible when highlighted using
the same fix that was used for secure sites and the URL bar (forcing the text to
be black when the background is highlighted yellow).


Comment 17

14 years ago
brian: does this also mean the Find Next/Previous should also be changed to
search within input and textarea? Or is that a separate bug?
(In reply to comment #17)
> brian: does this also mean the Find Next/Previous should also be changed to
> search within input and textarea? Or is that a separate bug?

Hm, it looks like that's a separate problem.  Find/Next/Previous uses
nsITypeAheadFind's find, while highlighting uses nsIFind.  Seems that TAF
doesn't search anonymous content, while nsIFind does.
(Assignee)

Comment 19

14 years ago
Fixed.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED

Updated

14 years ago
Keywords: fixed-aviary1.0
Comment on attachment 161961 [details] [diff] [review]
don't highlight text within INPUT or TEXTAREA 

removing obsolete review request
Attachment #161961 - Flags: review?(bryner)
Comment on attachment 162249 [details] [diff] [review]
alternate fix

This fix appears to be present on the trunk, so removing old request.
Attachment #162249 - Flags: review?(firefox)
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.