Closed Bug 256420 Opened 20 years ago Closed 18 years ago

Find toolbar doesn't disappear after 5 seconds if it was invoked with F3 (find next) or Shift + F3 (find previous)

Categories

(Toolkit :: Find Toolbar, defect)

defect
Not set
minor

Tracking

()

VERIFIED FIXED

People

(Reporter: 32768, Assigned: masayuki)

References

Details

(Keywords: fixed1.8.1)

Attachments

(1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040814 Firefox/0.9.1+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040814 Firefox/0.9.1+

The find toolbar usually times out and disappears after 5 seconds.  However,
this sometimes does not work.  For example, when you make the find toolbar
appear by pressing F3 (find next) it won't ever time out and must be closed
manually.

For consistency this should time out.

Reproducible: Always
Steps to Reproduce:
1. Press / and search for a term.
2. Wait 5 seconds for the toolbar to time out and disappear.
3. Switch to a different tab.
4. Press F3.

Actual Results:  
Find toolbar appears and never times out.

Expected Results:  
Find toolbar should appear but time out after 5 seconds (or not appear at all).
The reason the find bar re-opened was because the find field in the new tab was
blank.  You had never performed a find in the second tab.  The toolbar opens to
allow the user to enter a find.

I do agree that the find bar should time out in this condition, especially since
if there was a string available the bar would not even open.

The patch to fix this is included in the patch to fix Bug 250429.

With the patch in bug 250429, if you have never performed a find the toolbar
will open with a blank field, time-out, and then close (instead of remaining
open).  If you have performed a find, the previous find string will be used as
long as the findbar is not opened with text in the find field.  When combined
with the patch for bug 254523, if the "stored" find string is not found in the
new tab, the find bar will open to allow you to change the not-found string, and
then time-out to close.
Not just F3 but also Ctrl+F.  I wonder if this is the designed behavior.  I
notice that clicking to cause the Find field to lose focus doesn't close the
toolbar if it was shown using Ctrl+F or F3, but it does if it was shown with '/'.
Also, you cannot hit Control-F to close it after using Control-F to open it.
Tim, that's as designed.  See bug 250587.

Requesting blocking-aviary1.0.  Blake, is this as designed, to behave
differently depending on how the toolbar was invoked?
Flags: blocking-aviary1.0?
Why is this bug unconfirmed? Are we unsure that it's actually a problem?
(In reply to comment #5)
> Why is this bug unconfirmed? Are we unsure that it's actually a problem?

It's a problem.  It just needs somebody else to mark it as confirmed.
->new
setting -1.0
per bsmedberg
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Attached patch patch to fix (obsolete) — Splinter Review
Patch fixes the problem by setting gFindMode to FIND_LINKS or FIND_TYPEAHEAD
when ctrl-g or shift-ctrl-g is used with a hidden findbar & no find string and
also setting the FindClose timer.  The setting of gFindMode with a hidden
findbar follows the LinksOnly pref.
Attachment #162398 - Flags: review?(firefox)
Attachment #162398 - Flags: review?(firefox)
I can not duplicate this bug in Firefox 1.0 or 1.0+
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050621
Firefox/1.0+ ID:2005062110

WFM
The bug behaviour has changed.  Here are some new steps to reproduce:

1. Close and reopen the browser.
2. Press F3 when viewing a page

Actual Behavioiur:
Find toolbar appears and doesn't disappear after 5 seconds

Expected Behaviour:
Find toolbar disappears after 5 seconds
Bug no longer relevant as F3/findnext no longer brings up find toolbar.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
We don't know what fixed this, thus the bug is worksforme.
Status: REOPENED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → WORKSFORME
Sorry for the confusion caused by closing this bug.  The bug actually does still
exist.

F3 (find next) _does_ still invoke the find bar when no search has been done
previously.

This is actually still reproducable as described in comment #11.

Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Submitted bug #310882 to report a new regression in find toolbar re-appearing
which occurs in different circumstances to this one.
This bug can be invoked in different ways, which are described by different bug reports.  It can be invoked by first closing the Find bar either by (1) pressing the 'X' (bug 310882); (2) pressing <Esc> (bug 318466) or (3) by timeout (this bug).  It also does not matter whether "Begin finding as you type" is checked.

This bug covers failure to close the Find bar after timeout; bug 318466 covers failure to close after pressing <Esc>.  Bug 318466 is probably a duplicate of this one, but I am leaving it open to be sure any patch covers pressing <Esc>.

Changing the summary for accuracy.

The minimum steps to reproduce this bug:
1. Open the Find bar in any way and enter a nonexistent search string.
2. Close the Find bar in any way (timeout, press 'X', or press <Esc>).
3. Press F3.

Observed behavior:
1. Find bar does not close after 5 seconds.
2. Find bar does not close after pressing <Esc> key.

Expected behavior:
Find bar should close after 5 seconds or after pressing <Esc>.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Summary: Find toolbar doesn't disappear after 5 seconds if it was invoked with F3 (find next) → Find toolbar doesn't close correctly if it was invoked with F3 (find next)
Whiteboard: Check that any patch also fixes bug 318466 (probably a duplicate).
*** Bug 310882 has been marked as a duplicate of this bug. ***
*** Bug 318466 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051207 Firefox/1.6a1

This is fixed in trunk. If someone could find a de-regression range so I could figure out what bug fixed this, that'd be great. (That way I can mark this FIXED and depends-on the other bug which is better than WFM.)
Version: unspecified → 1.5 Branch
I don't think it is fixed.  For me, at first bug 318466 appeared to be fixed but not this one.  But when I changed tabs, I saw that neither is fixed.  Apparently it's unpredictable.  There are other recent changes in behavior as well.

I was about to argue that maybe this bug is invalid as stated because it omits mentioning until comment 16 that the search term should be nonexistent.  And now to complicate matters, it's erratic.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051207 Firefox/1.6a1
When I compair the behaviour of the current branch and trunk builds, I see that the findbar (invoked by F3) still doesn't disappear automatically after 5 seconds in both builds.
But in trunk it now reacts to the esc key. This is most likely fixed by Bug 305840 or Bug 306072. The only two bugs in this query with the word "findbar" in it. :)
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-08-26+10%3A00%3A00&maxdate=2005-08-26+12%3A00%3A00&cvsroot=%2Fcvsroot
I was talking about Windows XP.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051207 Firefox/1.6a1

OK, I figured it out.  This is how it behaves with the latest nightly.

1. Open the Find bar in any way and enter a nonexistent search string.
2. Close the Find bar in any way (timeout, press 'X', or press <Esc>).
3. Press F3.
4. Find bar will not timeout (bug?), but will close if you press <Esc> (correct behavior).
5. Press F3 again.
6. Click on the window so Find bar no longer has focus.
7. Find bar will not time out or close by pressing <Esc> (bug).

What do you think?  A new bug report?  Sorry for the bug spam.  This bug has evolved.
VanillaMozilla, it's usually not good practice to morph bugs into other bugs by changing summaries. FWIW, your steps to reproduce in comment 23 are slightly flawed. The findbar is not going respond to anything if it's not focused.

This bug is about the findbar not timing out and closing if it's invoked with F3, which is slightly debateable as to whether or not this is the correct behavior or not, IMO.
Assignee: firefox → nobody
Status: REOPENED → NEW
OS: Windows XP → All
QA Contact: fast.find
Summary: Find toolbar doesn't close correctly if it was invoked with F3 (find next) → Find toolbar doesn't disappear after 5 seconds if it was invoked with F3 (find next)
Whiteboard: Check that any patch also fixes bug 318466 (probably a duplicate).
taking this.

Should we suppress the find toolbar to be invoked by Find Next / Find Previous?
Assignee: nobody → masayuki
Hardware: PC → All
Summary: Find toolbar doesn't disappear after 5 seconds if it was invoked with F3 (find next) → Find toolbar doesn't disappear after 5 seconds if it was invoked with F3 (find next) or Shift + F3 (find previous)
Version: 1.5 Branch → Trunk
Attachment #162398 - Attachment is obsolete: true
(In reply to comment #25)
> taking this.
> 
> Should we suppress the find toolbar to be invoked by Find Next / Find Previous?
> 

I liked it when it returned focus to the find toolbar on a search term not found condition, because then you could modify the search term or hit escape without
having to mouse click in the find toolbar.

Reason for hitting find again even if search term not found initially is, 
1.if you did a find while page is still loading
2. want to modify search term by backspacing over last few characters, not necessarily the entire search term.
Ah... I have a mistake.

This bug has two problems.

1. If the find string is empty, the find toolbar is invoked by F3.
2. If the find string is not empty and is not found on current tab, the find toolbar is invoked by F3.

1:
We should not invoke the find toolbar, right?

2:
We should inherit the finding mode at find string inputted. I.e, if the find string is inputted by FAYT, we should close the find toolbar automatically. But if the find string is inputted by Ctrl+F, we should not close the find toolbar automatically, right?
I just tried it in 1.0.7:

(In reply to comment #27)
> Ah... I have a mistake.
> 
> This bug has two problems.
> 
> 1. If the find string is empty, the find toolbar is invoked by F3.
> 2. If the find string is not empty and is not found on current tab, the find
> toolbar is invoked by F3.

> 1:
> We should not invoke the find toolbar, right?

can continue to invoke the toolbar. However return focus to it after F3 invoked and search term not found. I just tried it in 1.0.7 and that is how it worked for case 1. 

Also 1.0.7 behavior is as described in case 2, except focus not returned to find toolbar in 1.5. Would like focus returned to toolbar as in 1.0.7.


> 2:
> We should inherit the finding mode at find string inputted. I.e, if the find
> string is inputted by FAYT, we should close the find toolbar automatically. But
> if the find string is inputted by Ctrl+F, we should not close the find toolbar
> automatically, right?

correct, I just tried it in 1.0.7 and that is how it worked.
NOTE:

Please use for testing Fx1.5 or Trunk builds.
I checked-in many many changes between Fx1.0 and Fx1.5.
In FAYT behavior, Fx1.0 and Fx1.5 are not compatible.
# And Trunk FAYT code and Fx1.5 FAYT code are not compatible too. See bug 313149.

>> 1:
>> We should not invoke the find toolbar, right?
> 
> can continue to invoke the toolbar. However return focus to it after F3 invoked
> and search term not found. I just tried it in 1.0.7 and that is how it worked
> for case 1. 

I think that we should not invode the find toolbar. Because if find string is empty, the F3 behavior is not defined as normal find mode(Ctrl + F) or FAYT mode. Not all users expect FAYT mode in case 1.
(In reply to comment #24)
FWIW, your steps to reproduce in comment 23 are slightly
> flawed. The findbar is not going respond to anything if it's not focused.

I agree.  Ignore comment 23 and most of comment 20.
*** Bug 334474 has been marked as a duplicate of this bug. ***
This bug was fixed by the fix for bug 340743.
Status: NEW → RESOLVED
Closed: 19 years ago18 years ago
Resolution: --- → FIXED
Note for clarity: "Find" mode never auto-dismisses, and continues to not auto-dismiss after the bar is restored via F3.  "Quick find" (FAYT) mode auto-dismisses, and now if you Quick find and then F3, we restore in Quick find mode, so we autodismiss properly.  In short, F3 now returns whatever bar ou had up previously, with whatever auto-dismissal behavior it had.
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.1
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: