251989 - Feedback missing on current highlighted text & cued search when findbar is opened

Status: NEW

(Toolkit :: Find Toolbar, defect, P5)

Description

[Michael Clackler]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040714 Firefox/0.9.1+ (MOOX-AV)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040714 Firefox/0.9.1+ (MOOX-AV)

If text is highlighted and the toolbar closes, when the toolbar re-opens, the
text remains highlighted but there is nothing shown in the toolbar "find" field.
 This is confusing when you re-open the find bar, see no text requested to be
found, and text is highlighted on the page.  It looks like the highlighted text
was not requested by the toolbar.

I would suggest that if text is highlighted when the find toolbar is opened, the
currently highlighted text is present in the "selected" state in the "Find"
field.  I hope I am using the correct terminology.  By "selected" I mean the
text in the "Find" field should itself be highligted and if any key is pressed,
the text should be replaced with the new entry.  This provides feedback to the
end user that the currently highlighted text in the document should be
highlighted, and ties the currently highlighted state to the findbar.  Since the
 currently highlighted text is "selected" in the "find" field, it also would not
break any of the FAYT since as soon as you start typing, the text would be replaced.

Reproducible: Always
Steps to Reproduce:
1.Open the find toolbar, find a phrase, and select highlight.
2.Allow the find toolbar to close (or close it)
3.Open the find toolbar again

Actual Results:  
The document has highlighted text, but the "Find" field in the toolbar shows no
text requested to be found.

Expected Results:  
The document has highlighted text and the "Find" field in the toolbar should
show in the "selected" state the same text that is "highlighted" in the document.

Comment 1

[Michael Clackler]

I also noticed that the same feedback is needed to inform the user of a find "in
cue".  If you open the find bar to find the first location of a phrase, and the
toolbar auto-closes, when you re-open the bar, the "find" field is blank.  If
you did not know the previous find was still "in cue" and all you had to do is
hit find next or previous, the user would probably get upset because the bar
closed and "erased" the find they had entered in the bar.  Since the find field
is blank, the user will think they have to re-enter what the phrase they typed
before the toolbar auto-closed.  If the last find performed before the toolbar
auto-closed was successfull, when the toolbar is re-opened, the previous found
phrase should be present in the find field as defined above.

Comment 2

[Jon Henry]

Michael, do you still see this behavior in a more recent nightly build? I cannot
reproduce this bug.

Comment 3

[Michael Clackler]

(In reply to comment #2)
> Michael, do you still see this behavior in a more recent nightly build? I cannot
> reproduce this bug.

Yes, it's still there.  I just noticed I did not specify this does not happed
when using ctrl-F, it just occurs using FAYT / or '.  Line 412 in browser.js
clears the text field when the find bar is opened using / or '.  I'm looking at
a way to get around this now.

If you use ctrl-F, the desired feedback is present.

Comment 4

[Jon Henry]

Oh, now I see what you mean. Marking NEW.

Comment 5

[Michael Clackler]

Attachment: patch to fix

This patch corrects the problem when using '/' to initiate the find bar. 
Sadly, we can not select the find field using ' to initiate the find bar since
it removes the focus from the URL's you find.  This patch leaves the default
behavoir of clearing the find field when the bar is initiated with '.

The patch also corrects a very minute nit where /* '*/ should be /* ' */

Comment 6

[Michael Clackler]

Comment on attachment 154855 [details] [diff] [review]
patch to fix

request review

Comment 7

[Michael Clackler]

The patch included above also fixes bug 253903.

Comment 8

[Michael Clackler]

requesting blocking-aviary1.0PR since patch exists

Comment 9

[Mathieu Pellerin]

+ you run on bug 253903 so often it's a very irritating bug for anyone who got
used to use fayt.

Comment 10

[chris hofmann]

*** Bug 253903 has been marked as a duplicate of this bug. ***

Comment 11

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 154855 [details] [diff] [review]
patch to fix

r+a=[e-mail]

Comment 12

[Michael Clackler]

Ben,

I'm not sure, but if I rememeber correctly this patch caused a problem with the
focus of links.  I need to check this out.  Also, the patch is from a 2 month
old copy of browser.js and needs to be updated as long as if works

Comment 13

[Mathieu Pellerin]

I stopped using this nice feature in firefox because the "find next" when
pressing enter is not working, would be nice if this patch doesnt miss the 1.0
final release

Comment 14

[Ben Goodger (use ben at mozilla dot org for email)]

What happens with links? Can you tell me how to reproduce, I've your patch
applied in my build...

Comment 15

[Michael Clackler]

(In reply to comment #14)
> What happens with links? Can you tell me how to reproduce, I've your patch
> applied in my build...

Ben,
The problem is that with the patch installed the findbar has the focus when
using "/" to open the bar.  Because the bar has the focus, when a url is
currently "find selected" pressing "enter" does a "find next" instead of opening
the url.  

With the "old" FAYT (on trunk builds), if a URL is found using ' or /, pressing
"enter" opens the URL.  With this patch, using the text search string "/" to
open the find bar does not allow the URLs to be opened using "enter", but does
allow the URL search string "'" to open URLs using "enter".

The patch does solve the problem identified in the bug, but it will involve a
mindset change for "old" users used to FAYT to allways use the URL search string
"'" to open the find bar if they want to follow links using "enter".  

Comment 16

[Mathieu Pellerin]

I thought that by definition the "/" would not focus on links and the " ' " key
would ... thats the way it used to work (before the new find toolbar)

Comment 17

[sairuh (rarely reading bugmail)]

(In reply to comment #16)
> I thought that by definition the "/" would not focus on links and the " ' " key
> would

/ focuses both non-linked and linked text, whereas ' focuses only linked text.

Comment 18

[Tim Martin]

Surely if a link has become focused, it should respond consistantly to input? 
Having the behavior of a keystroke (such as enter) depend upon the manner in
which a link gets selected doesn't seem all that user friendly.

Comment 19

[Steffen Wilberg]

Ben checked this into the branch 2004-10-13 15:22.

Comment 20

[Adrian Yee]

This change has really been bugging me since it was included in the 20041014
build.  / has always (well that I can remember) made it possible to follow links
by pressing enter when selected.  If you want to press enter for the next
result, use Ctrl+F.  I guess the change makes, but now Ctrl+F and / do the same
thing.

Comment 21

[Blake Ross]

I backed out the patch. We can't change the behavior of /, it's too ingrained i
users' minds. Can someone give me better steps to reproduce this bug? From
comment 0, I wasn't really able to reproduce it. When the toolbar reopens, the
previous find string is present again.

Comment 22

[Asa Dotzler [:asa]]

This bug seems to have an aviary branch checkin associated with it. If this has
landed on the aviary branch (as much as it's going to for 1.0) can you please
add the "fixed-aviary1.0" keyword? Thanks.

Comment 23

[Nickolay_Ponomarev]

I can reproduce following the same exact steps as described in comment 0.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041106 Firefox/1.0

1. type "/vote"
2. highlight
3. close find toolbar
4. type "/"

after step 4 the find toolbar's textbox is empty, although all occurences of
"vote" are highlighted.

this also causes bug 267633 which is a dupe, but since this bug is claimed to be
unreproducable etc, I'll add a dependancy instead.

Comment 24

[Jorge Villalobos [:jorgev] (he/him)]

(In reply to comment #23)
> I can reproduce following the same exact steps as described in comment 0.
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041106
Firefox/1.0
> 
> 1. type "/vote"
> 2. highlight
> 3. close find toolbar
> 4. type "/"
> 
> after step 4 the find toolbar's textbox is empty, although all occurences of
> "vote" are highlighted.
> 
> this also causes bug 267633 which is a dupe, but since this bug is claimed to be
> unreproducable etc, I'll add a dependancy instead.

Attachment 186103 [details] [diff] from Bug 297369 affects this bug in the following way: after
step 4 the find bar's textbox is empty and the highlighting of "vote" occurences
is removed.