628179 - Close the find bar when navigating away from the current page

Status: REOPENED

(Firefox :: General, defect)

Description

[Andreas Gal :gal]

If I bring up the find bar with, it persists page navigation and sticks around forever eating up useless screen real estate. Its gray and innocuous enough that I usually don't notice for a while. I think in almost all circumstances the user wants the find bar to go away once navigation happens. We spent so much effort reclaiming the status bar space. This seems really a waste in comparison.

Comment 1

[Andreas Gal :gal]

Attachment: patch

Comment 2

[Alex Limi (:limi) — Firefox UX Team]

Comment on attachment 506283 [details] [diff] [review]
patch

This is a good, simple first step — the find bar has lots of issues, but this would be a simple improvement that I'd like to see.

Comment 3

[Patrick Walton (:pcwalton)]

Drive-by feedback+. I'd like to see this.

Comment 4

[Shawn Wilsher :sdwilsh]

Not going to block on this, but we'd probably approve a reviewed patch!

Comment 5

[Patrick Walton (:pcwalton)]

Comment on attachment 506283 [details] [diff] [review]
patch

Switching review to dolske since I suspect Gavin is overloaded.

Comment 6

[Brendan Eich [:brendan]]

This has a patch, so that DUPEME should not blindly resolve this a dup of an old bug without a patch. Dup forward, or move the patch and assignment.

/be

Comment 8

[Reed Loden [:reed]]

Duped the main one I found, but I think there are a few others as well. There are some interesting (and useful) thoughts in bug 537013 that probably should be considered...

Seems while the find bar code lives in toolkit/, this patch is just for browser/, so reverting my earlier change.

Comment 9

[Dão Gottwald [:dao]]

It should be noted that this patch closes the find bar when switching tabs, and doesn't reopen it when going back to the tab that had it open.

Comment 10

[Dão Gottwald [:dao]]

Comment on attachment 506283 [details] [diff] [review]
patch

And if you do this, this code needs to be removed:
http://hg.mozilla.org/mozilla-central/annotate/dd74bee1601c/browser/base/content/tabbrowser.xml#l923

Comment 11

[Patrick Walton (:pcwalton)]

Attachment: Proposed patch, version 2.

Patch version 2 fixes the issue. Review requested.

Comment 12

[Dão Gottwald [:dao]]

Comment on attachment 508475 [details] [diff] [review]
Proposed patch, version 2.

>--- a/browser/base/content/tabbrowser.xml
>+++ b/browser/base/content/tabbrowser.xml
>@@ -588,16 +588,20 @@
>                 if (this.mBrowser.registeredOpenURI) {
>                   autocomplete.unregisterOpenPage(this.mBrowser.registeredOpenURI);
>                   delete this.mBrowser.registeredOpenURI;
>                 }
>                 if (aLocation.spec != "about:blank") {
>                   autocomplete.registerOpenPage(aLocation);
>                   this.mBrowser.registeredOpenURI = aLocation;
>                 }
>+
>+                // Close the Find bar if it's open.
>+                if (!gFindBar.hidden)
>+                  gFindBar.close();
>               }
> 
>               if (!this.mBlank) {
>                 this._callProgressListeners("onLocationChange",
>                                             [aWebProgress, aRequest, aLocation]);
>               }
> 
>               if (topLevel)

As opposed to the browser.js chunk in the first patch, this looks wrong. It's code that runs for background tabs.

(Did you ask Andreas before stealing the bug?)

Comment 13

[Andreas Gal :gal]

Its always ok to steal from me. Patrick knows this code a lot better than me.

Comment 14

[Patrick Walton (:pcwalton)]

Attachment: Proposed patch, version 3.

Here's a new version of the patch. It adds a new event listener to the browser that fires only when the current tab navigates, and uses that to hide the Find bar.

Comment 15

[Dão Gottwald [:dao]]

I didn't r- the first patch because of comment 9. It's a tradeoff we need to be aware of if we take the patch.

I don't think hiding the find bar when navigating but not when switching tabs is a fundamentally better tradeoff, as the navigation hiding the find bar could happen on a page that you didn't open the find bar for, which is weird.

Comment 16

[Patrick Walton (:pcwalton)]

Attachment: Proposed patch, version 4.

Ah, I misunderstood, sorry. Here's version 4 which goes back to the way Andreas originally had it, with the changes you requested.

Comment 17

[Patrick Walton (:pcwalton)]

Attachment: Proposed patch, version 5.

Patch version 5 fixes indentation.

Comment 18

[Dão Gottwald [:dao]]

Comment on attachment 508522 [details] [diff] [review]
Proposed patch, version 5.

>-      // fix bug 253793 - turn off highlight when page changes
>-      gFindBar.getElement("highlight").checked = false;      

This change means highlighting would be enabled if you re-open the find bar. We probably don't want that.

>--- a/browser/base/content/tabbrowser.xml
>+++ b/browser/base/content/tabbrowser.xml

>-                // Otherwise, focus the content area.
>+                // Focus the content area.

It's still "otherwise", i.e. when not focusing the location bar.

Comment 19

[Alice0775 White]

I think this is not convenient.

1. Gmail &  Yahoo Japan mail
When a page searches an email, FindBar is closed just to have chosen the next older email.

2. Web search(Google/Yahoo etc)
Open several search result open in New Tab. And I want to find word in the newly opened tab continuously.FindBar is closed just to switch a tab.

This is no good IDEA.

Comment 20

[Andreas Gal :gal]

With the current state you have to pay a "toolbar tax" as limi put it. If you search once, you globally lose screen real estate until you remember to close the find bar. Brendan pointed out that in most FF screenshots on the web you can see the findbar displayed. Its always sitting there, doing nothing. On top of that we currently have the add-on bar, also refusing to hide itself. We lose twice as much to this issue than we saved with getting rid of the status bar.

As for your use case, the temperature of the bottom part of the browser is basically sub-zero:

https://heatmap.mozillalabs.com/mozmetrics/

I don't think a relevant fraction of our users do this kind of global search frequently.

Comment 21

[Alex Limi (:limi) — Firefox UX Team]

(In reply to comment #20)
> On top
> of that we currently have the add-on bar, also refusing to hide itself. 

That's an unrelated issue, but it's being tracked in bug 627484.

Comment 22

[Dão Gottwald [:dao]]

(In reply to comment #20)
> With the current state you have to pay a "toolbar tax" as limi put it. If you
> search once, you globally lose screen real estate until you remember to close
> the find bar.

... or restart the browser, right?

Comment 23

[Finn Bryant]

I doubt this could be done so close to release, but just wanted to suggest what a "correct" fix might consist of:


If you treat the find bar as per-tab (not my preference, but not a terrible idea), it should be enabled/disabled per tab (the patch is half-way there with disabling it on any navigation), it might also be worth considering making the text to search for tab-specific, but that could be argued both ways in my opinion, no point making UI less useful just to fit with a paradigm. 

If you treat it per-window, then it shouldn't be removed on any navigation, which is clearly going against the intent of this bug, but any solution involving navigation is inconsistent and reduces usability in some situations (though it *does* solve the problem, so shouldn't be completely discounted). However, a better solution presents itself, if the find bar is not used for a certain period of time (maybe 5 mins), it closes itself. This should include use of shortcuts related to the find bar too. Also, it shouldn't disappear if the user has any webpages currently highlighted (yes, that means those with silly numbers of tabs open could get stuck with it if they leave one open in this state, but it should only be a minority of a minority getting a minor reduction in screen real estate if they forget about pressing the close button, so not too worrying)

There is an issue with the close-timer approach, it may distract/confuse the user when it disappears, but since its at the bottom, it shouldn't be too jarring (wont mess with most webpages layout), in fact, the problem iteslf suggests this UI isn't very noticeable.

An advantage to the timer is that users (and esspecially those who aren't shortcut aware and have to use the menu) wouldn't have to continually reopen it to search around multiple pages.

Again, this is probably too much to get into Firefox 4, but since we're either going to end up with no fix or a quick fix, this solution could replace it for the next release, so better to get it considered early so it doesn't end up too late again like this time.

Comment 24

[Andreas Gal :gal]

comment 22: I restart my browser once a week or so. That's not really a good fix I think.

comment 23: I completely agree that a per-tab find bar is exactly what we need and I hope that's on the radar of the front-end team for FF5. This patch is a 1-liner that changes behavior that is almost always wrong to behavior that is almost always better, but certainly far from perfect.

Comment 25

[Dão Gottwald [:dao]]

(In reply to comment #24)
> comment 22: I restart my browser once a week or so.

Ok, but think I think you're part of a minority here.

> That's not really a good fix I think.

I'm not saying it's a fix, but it puts this bug in a different perspective. This needs to be weighted carefully against cases like those mentioned in comment 19.

Comment 26

[Andreas Gal :gal]

People close their browser frequently? Do you have evidence to back this up? Did we collect data on this?

Comment 27

[Dão Gottwald [:dao]]

I'm primarily thinking of people completely shutting down their computer and thus necessarily quitting the browser. On most operating systems this is the standard shutdown method, as far as I know.

By the way, somehow I must have missed this part of your earlier comment:

(In reply to comment #20)
> As for your use case, the temperature of the bottom part of the browser is
> basically sub-zero:
> 
> https://heatmap.mozillalabs.com/mozmetrics/
> 
> I don't think a relevant fraction of our users do this kind of global search
> frequently.

The heat map doesn't cover the find bar at all. Even if it told you how many users opened the find bar, that number would be pretty useless. This bug only kicks in once the user has opened the find bar.

Comment 28

[Brendan Eich [:brendan]]

Does the patch in this bug make Firefox better on balance or not? Worse is not always better, but pretty often it is, because as rpg's famous essay notes, it actually gets users and the producer or worse then can iterate in later releases.

So, what's the hold-up here?

/be

Comment 29

[Dão Gottwald [:dao]]

(In reply to comment #28)
> Does the patch in this bug make Firefox better on balance or not?

I don't know. It probably does for Andreas but not for Alice0775 White. Personally, I always hit ESC when I'm done with the find bar.

Comment 30

[Shawn Wilsher :sdwilsh]

Why don't we ask the UX team then...

Comment 31

[Brendan Eich [:brendan]]

(In reply to comment #30)
> Why don't we ask the UX team then...

Limi wrote comment 2.

The plain fact is the find bar gets stuck for most users most of the time. This bug is not invalid. So long as it remembers the last text-to-find, closing it does not seem like a hardship. Alice?

/be

Comment 32

[Alice0775 White]

(In reply to comment #31)
> (In reply to comment #30)
> > Why don't we ask the UX team then...
> 
> Limi wrote comment 2.
> 
> The plain fact is the find bar gets stuck for most users most of the time. This
> bug is not invalid. So long as it remembers the last text-to-find, closing it
> does not seem like a hardship. Alice?
> 
> /be

I think FAYT covers this Bug and your requirement.

Comment 33

[Dão Gottwald [:dao]]

(In reply to comment #31)
> (In reply to comment #30)
> > Why don't we ask the UX team then...
> 
> Limi wrote comment 2.

Various things to consider have been mentioned after comment 2.

Comment 34

[Brendan Eich [:brendan]]

(In reply to comment #32)
> I think FAYT covers this Bug and your requirement.

I like quick-find, but it does not suffice to get rid of irrelevant find bars for most users that stick around tying up space for the life of the window.

And there are reasons to type ctrl-F or cmd-F instead of invoking quick-find to start a find in page. One reason they do this instead of quick-find is when focus is on an input element.

But since most finds are topical, the find bar sticking around on later pages is usually not wanted. If it's needed again with the remembered text, it can be re-invoked (unlike quick-find).

We have long had quick-find and the sticks-around-too-long full find bar. These were split from the Firefox 1 era find bar to try to satisfy both parties (those who used the find gesture formerly linked to a dialog box; those who wanted quick find AKA FAYT). But as usual with a "do both" compromise, neither user base was fully satisfied, and the total result was more complicated.

This bug is not about "fixing" find in all its complexity. That's a challenge for the future.

This bug is about hiding the find bar on navigation. In the old days, the find dialog not only would tend to obscure one instance of the text being found, but it might stick around across page navigation, as non-modal dialogs are supposed to do on some platforms and in some browsers.

But! Asa recently reminded me that when we worked out the Firefox 1 find bar, we actually did regress this case. The find dialog we had up to that point used to auto-dismiss on navigation but the new find bar did not.

Anyway, with a non-dialog toolbar at bottom of page, we do not have to preserve that API (not according to any HIG or such thing).

So my question remains: is reinvoking the find bar with the remembered text sufficient for your use-case? Is it too much of a hardship?

The excess escapes that Dao types constitute a keystroke, cognitive load, and "flow" tax. He may be used to them, but they're not a mandatory perpetual tax.

So for this bug, can we consider lowering that tax and raising the re-invoke tax on Alice and others who expect the find bar to stick around across navigation?

(In reply to comment #33)
> (In reply to comment #31)
> > (In reply to comment #30)
> > > Why don't we ask the UX team then...
> > 
> > Limi wrote comment 2.
> 
> Various things to consider have been mentioned after comment 2.

Indeed. Limi, any new thoughts?

/be

Comment 35

[Alice0775 White]

>Alice and others who expect the find bar to stick around across
navigation?
Yes.
When I have finished using it, I close it.

Comment 36

[Robert Sayre]

Data points:

Opera: findbar closed on navigation
Safari: findbar closed on navigation
Chrome: findbar closed on navigation

Comment 37

[Alice0775 White]

This bug
Nav, Open FindBar,  Nav, Open FindBar, Nav, Open FindBar, Close Findbar
You should operate 4times

Recent:
Nav, Open FindBar,,  Nav, Nav, Close Findbar
only 2 Times

Which is low cost?

Comment 38

[Alice0775 White]

if I want to use FindBar for 3 pages;

This bug
Nav, Open FindBar,  Nav, Open FindBar, Nav, Open FindBar, Close Findbar
You should operate 4times

Recent:
Nav, Open FindBar, Nav, Nav, Close Findbar
only 2 Times

Which is low cost?

Comment 39

[Dão Gottwald [:dao]]

Getting to parity with Opera, Chrome and Safari would mean to fix bug 537013, I think. This bug suggests compromise (and the summary is rather poor); all patches so far made made tradeoffs that other browsers don't make.

Comment 40

[Brendan Eich [:brendan]]

Dao: what should this bug's summary say?

/be

Comment 41

[Brendan Eich [:brendan]]

(In reply to comment #37)
> This bug
> Nav, Open FindBar,  Nav, Open FindBar, Nav, Open FindBar, Close Findbar
> You should operate 4times
> 
> Recent:
> Nav, Open FindBar,,  Nav, Nav, Close Findbar
> only 2 Times
> 
> Which is low cost?

This is your use-case. The more common case in my experience, and I'd bet real money in the case of many users, is to find in only some pages in a navigation sequence. I'd guess < one in four pages (I find a lot), which makes the odds of lingering on a page with the find bar uselessly hanging out below pretty good.

/be

Comment 42

[Dão Gottwald [:dao]]

(In reply to comment #40)
> Dao: what should this bug's summary say?

It should at least mention tab switching. I'm not sure this was part of the original plan, but it's what the patches do.

Comment 43

[Dão Gottwald [:dao]]

Also, does "navigation" mean only top-level location changes or location changes sub documents as well?

Comment 44

[Dão Gottwald [:dao]]

Let me try that again with less typos: Does "navigation" mean only top-level location changes or location changes in sub documents as well?

Comment 45

[Brendan Eich [:brendan]]

(In reply to comment #44)
> Let me try that again with less typos: Does "navigation" mean only top-level
> location changes or location changes in sub documents as well?

Pretty clearly top-level only -- what did the patch do?

/be

Comment 46

[Dão Gottwald [:dao]]

If I read it correctly, the patch would close the find bar for location changes in sub documents.

Comment 47

[Shawn Wilsher :sdwilsh]

This all sounds very testable.  Future patches are going to include those, right?

Comment 48

[Andreas Gal :gal]

-    if (gFindBarInitialized) {
-      if (gFindBar.findMode != gFindBar.FIND_NORMAL) {
-        // Close the Find toolbar if we're in old-style TAF mode
-        gFindBar.close();
-      }

...

+    // Close the Find bar when navigating.
+    if (gFindBarInitialized)
+      gFindBar.close();


The patch changes one line: instead of closing the find bar only if a quick find was in progress, I always close it even if a regular find was in progress. Whatever navigation was deemed appropriate to close the quick find bar seems appropriate to also close the find bar. If we should exclude certain types of sub-document navigation (and if we don't already do that), that's a separate bug. Lets file it.

The patch has UI review from limi. If you feel his review was in error, you should contact him and ask him to take it back. Until then his r+ stands I would assume.

So can we please just land this trivial fix?

We have gone 47 comments on a 1-liner fix to fix an annoying find bar issue that is clearly contrary to the design we are headed to: get chrome out of the user's face and make room for content. This really shouldn't be this hard.

And as for tests, we are happy to write them after we have a reviewed patch. With the amount of push back we have gotten in this bug I would like to be certain that that effort isn't wasted before writing the tests.

Comment 49

[Patrick Walton (:pcwalton)]

Attachment: Proposed patch, version 6.

Patch version 6 addresses Dao's comments on version 5 and adds a test.

Comment 50

[Patrick Walton (:pcwalton)]

Attachment: Proposed patch, version 7.

Patch version 7 fixes a bogus removeEventListener() call in the test.

Comment 51

[Dão Gottwald [:dao]]

(In reply to comment #48)
> The patch changes one line: instead of closing the find bar only if a quick
> find was in progress, I always close it even if a regular find was in progress.
> Whatever navigation was deemed appropriate to close the quick find bar seems
> appropriate to also close the find bar. If we should exclude certain types of
> sub-document navigation (and if we don't already do that), that's a separate
> bug. Lets file it.

Quick find is most likely less commonly used, so I'm not okay with copying glitches it might have over to normal find mode.

Comment 52

[Dão Gottwald [:dao]]

Comment on attachment 509976 [details] [diff] [review]
Proposed patch, version 7.

>--- a/browser/base/content/browser.js
>+++ b/browser/base/content/browser.js
>@@ -4421,24 +4421,19 @@ var XULBrowserWindow = {
>         if (disableFind)
>           elt.setAttribute("disabled", "true");
>         else
>           elt.removeAttribute("disabled");
>       });

^^^^^^

I think this is the point where you can hide the find bar for top-level location changes. Please cover sub document navigation as well as tab switching in the test as well.

>     }
>     UpdateBackForwardCommands(gBrowser.webNavigation);
> 
>+    // Close the Find bar when navigating.
>     if (gFindBarInitialized) {
>-      if (gFindBar.findMode != gFindBar.FIND_NORMAL) {
>-        // Close the Find toolbar if we're in old-style TAF mode
>-        gFindBar.close();
>-      }
>-
>-      // XXXmano new-findbar, do something useful once it lands.
>-      // Of course, this is especially wrong with bfcache on...
>+      gFindBar.close();

Comment 53

[:Gavin Sharp [email: [e-mail]]]

Yeah, the existing fast-find behavior is a bug, so we should fix it here (it's easy). We make the mistake of not properly filtering subdocument loads too often :(

Comment 54

[Patrick Walton (:pcwalton)]

Attachment: Proposed patch, version 8.

Patch version 8 makes the Find bar not go away on subdocument navigation and adds a check for this to the test case.

Comment 55

[Dão Gottwald [:dao]]

Comment on attachment 510400 [details] [diff] [review]
Proposed patch, version 8.

>+      // Close the Find bar when navigating.

This tells only half of the truth.

>+      if (gFindBarInitialized)
>+        gFindBar.close();

Unfortunately this method isn't as smart as one would think. Since you're calling it frequently here, can you let it return early when the find bar is already hidden?

Comment 56

[Patrick Walton (:pcwalton)]

Attachment: Proposed patch, version 9.

Patch version 9 makes the suggested changes.

Comment 57

[Dão Gottwald [:dao]]

Comment on attachment 510451 [details] [diff] [review]
Proposed patch, version 9.

>+      // Close the Find bar if it's open when the top-level document navigates.

This still fails to mention tab switching. But since these conditions apply to the whole surrounding code block, you can just remove the comment.

>       // fix bug 253793 - turn off highlight when page changes
>       gFindBar.getElement("highlight").checked = false;      

Judging by bug 253793, this should probably move up into the top-level-only section as well...

Comment 58

[Patrick Walton (:pcwalton)]

Attachment: Proposed patch, version 10.

Patch version 10 addresses review. Requesting approval for this low-risk change that fixes a UI papercut.

Comment 59

[Shawn Wilsher :sdwilsh]

Comment on attachment 510482 [details] [diff] [review]
Proposed patch, version 10.

a=sdwilsh, but if this bounces, it bounces hard (so make sure it's all green on try server first).

Comment 60

[Patrick Walton (:pcwalton)]

http://hg.mozilla.org/mozilla-central/rev/9d8d272b9314

Comment 61

[B.J. Herbison]

(In reply to comment #0)
> I think in almost all circumstances
> the user wants the find bar to go away once navigation happens.

Sorry to come in at this stage, but do you have data to support that premise? Have there been any user interaction studies that record how often users will search for the same term again after a page reloads or on multiple tabs?

I don't assume that my usage is typical, but the new behavior is quite annoying for me. I frequently search for the same term on multiple tabs and reload a page and want to search for the same term -- now I have to reopen the find bar regularly. I even opened bug 634454 because I assumed the vanishing search bar was an unintended consequence of some other change.

Comment 62

[Andreas Gal :gal]

This bug is closed. Lets move any discussion over to your new bug.

Comment 63

[Teodosia Pop]

Verified using Mozilla/5.0 (Windows NT 6.1; rv:2.0b12) Gecko/20100101 Firefox/4.0b12.

Comment 64

[eyal gruss]

findbar closes on subdomain navigation in beta 12. should this bug be reopened or is there another bug for that?

Comment 65

[Shawn Wilsher :sdwilsh]

(In reply to comment #64)
> findbar closes on subdomain navigation in beta 12. should this bug be reopened
> or is there another bug for that?
Regardless, you should not reopen this bug.  Either file a new one, or find an existing one.

Comment 66

[Mike Beltzner [:beltzner, not reading bugmail]]

We should back this out, and unapprove the patch. It's making bug 637224 more apparent, and we're into reducing risk.

Comment 67

[:Gavin Sharp [email: [e-mail]]]

I agree with the proposal to back out - I think bug 634454/bug 634440 are the more compelling reasons, though.

Comment 68

[Mike Shaver (:shaver emeritus)]

yep.

Comment 69

[Brendan Eich [:brendan]]

Agreed. We will need to make bigger (but not too big to fit the release cycle) changes for next time to make enough progress to stick.

/be

Comment 70

[Patrick Walton (:pcwalton)]

(In reply to comment #66)
> We should back this out, and unapprove the patch. It's making bug 637224 more
> apparent, and we're into reducing risk.

On it.

Comment 71

[:Gavin Sharp [email: [e-mail]]]

Attachment: backout patch

This backs out the functional change, while maintaining the other bug fix (subframe behavior). Also keeps part of the test coverage that's still applicable - this might not be very useful, given that we don't autoclose in normal mode at all, so we could just remove it too.

Comment 72

[Patrick Walton (:pcwalton)]

Comment on attachment 515703 [details] [diff] [review]
backout patch

Looks fine to me. 

Glad you cc'd me on this, by the way! I forgot that my patch fixed the subframe navigation bug for old-style type-ahead find. I was about to back that bug fix out along with the rest of the patch.

Comment 73

[Patrick Walton (:pcwalton)]

http://hg.mozilla.org/mozilla-central/rev/55c573e5eb6c

Comment 74

[Derek]

This bug will be a major usability problem if fixed. Example: if you need to search for the same thing on more then one tab, Then not only will we have to reopen the find bar each time but we will have to retype our search term each time, I honestly think most people don't mind it being open or they would just close it themselves, I think the majority of people do not want it to auto close for this fact alone. Not trying to spam, I just think this is a bad idea for the general population of Mozilla Firefox users. If this is implemented then there needs to absolutely be an easy to set option (not just about:config tweak) for the majority to change it if they wish.

Comment 75

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Thus bug should be WONTFIXed!

I often search some text across many sites in different tabs and landing this
bug will cause more work to do for people like me, like Derek said
> if you need to
> search for the same thing on more then one tab, Then not only will we have to
> reopen the find bar each time but we will have to retype our search term each
> time,

What's the pros in fixing this ? Because now all I can see is cons...

Comment 76

[gadjo]

(In reply to comment #74)
> Then not only will we have to
> reopen the find bar each time but we will have to retype our search term each
> time, 

No, you don't have to - just press F3

Comment 77

[Andreas Eibach]

(In reply to comment #75)

>Thus bug should be WONTFIXed!

>I often search some text across many sites in different tabs and landing this
>bug will cause more work to do for people like me, like Derek said

Yup. May I also repeat my use case again (without repeating myself, that is)

Please see bug 634454 comment #8.

Comment 78

[Derek]

(In reply to comment #76)
> (In reply to comment #74)
> > Then not only will we have to
> > reopen the find bar each time but we will have to retype our search term each
> > time, 
> 
> No, you don't have to - just press F3

Sorry i missed that part as i was up late and tired at the time, I would however want to point another big major reason to wontfix this and that is for this fact, 

The majority of people who use computers are computer illiterate in a sense, They just know a few basic things, Point and click, browse and type, X to close, and usually don't use hotkeys or even know them and i see this all the time with about everyone i know who has a computer or uses a computer except for a few, my parents included and they have had computers since 1995. 

Basically the majority will go about it the long way by clicking the menu and then find to bring up the find bar so i imagine that would get annoying or frustrating for beginners or the average PC user. These facts need to be taken into consideration, Most will just close the find bar when they are done by pressing X so the way it is now isn't a big deal at all.

This being fixed won't effect our advanced users so much as we will just change it back for ourselves. It is the average user that it is going to effect the most. I'll leave it at that. Last comment from me as i made my case and wanted to put another take on this before this is fixed / final.

Comment 79

[Andreas Gal :gal]

Comment on attachment 515703 [details] [diff] [review]
backout patch

Removing approval flag. Backout happened.

Comment 81

[Ken Winiecki, Jr.]

Late to the party, sorry.  I vote for some kind of change.  There are uses for a persistent Find Bar, but the Ctrl+F/Ctrl+G default behavior I think would be better impersistent, with persistence accessible some other way.  I think most users of Ctrl+F/Ctrl+G would prefer the more streamlined experience of not having to manually close something that could be closed automatically.  I also think it is more of a focus issue than a navigation issue:

- Ctrl+F should move the focus to a bar, opening one if necessary (as Firefox does)
- hitting Enter in a "Ctrl+F Bar" should close it and search
- Ctrl+G should search and close any open Ctrl+F Bar (never open one)
- tabbing/mousing focus off a Ctrl+F Bar should close it

I can see two approaches:  closing the Find Bar on loss of focus (and stopping Ctrl+G failure from opening it), or changing the association of Ctrl+F/Ctrl+G to the less-persistent Quickfind Bar and coming up with a different way to access the persistent Find Bar.

Comment 82

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

It's BIG FAIL if you want to:
-search sth between multiple tabs in one window
-search some word on the site and quick modify it if too many where found
-multiple search for many words only to see if they exist on the page
etc...

Just make "Auto-hide" option near "Match case" which be enabled by default and both sides will be happy.
It's not that hard and promoting/supporting only one side is a bad idea!

Comment 83

[Andreas Eibach]

I agree, this is the wrong way to go.

*I* always need the Find Bar to be open *permanently* unless I close it by hand because I want to.
But as others DO need the auto-hide (what Virtual_ManPL means is identical to my "pinning" technique, since the behavior will be the same in the end), why not have a way to toggle it on-off?

Comment 84

[devendra]

(In reply to Dão Gottwald [:dao] from comment #39)
> Getting to parity with Opera, Chrome and Safari would mean to fix bug
> 537013, I think. This bug suggests compromise (and the summary is rather
> poor); all patches so far made made tradeoffs that other browsers don't make.

Comment 86

[Lindsey]

Is there an ETA on this auto-hide behavior? I'm so looking forward to this bug-fix.

Comment 87

[Lindsey]

I don't understand the hold up on fixing this bug!

1.) even if the Find Bar autohides, tapping F3 initiates the same search in other tabs. The user doesn't have to "retype" the find request.

2.) Even if the Find Bar autohides, pressing Ctrl+F reveals it again and what the user typed is still there. So the user doesn't lose what was typed when it hides.

3.) If the Find Bar is not hidden and stays always visible, it still loses input-focus during the act of web browsing. So the user still has to tap Ctrl+F to get it to have input-focus again--THE EXACT SAME THING THE USER HAS TO DO TO MAKE A HIDDEN FIND BAR UNHIDE.

When I want to find something, I open the Find Bar and type my search. When I move to a new webpage or a new tab I want the Find Bar to autohide so it is not taking up real estate on my small netbook screen. 

Since I can still perform the exact same search by tapping F3 even when the find bar is hidden. And I can reveal the Find Bar after it autohides and still see the last search I typed. And the act of revealing the Find Bar is the same act that is required to get input-focus back onto the Find Bar--

What is the Problem with hiding the Find Bar?

Please fix this already!

Comment 88

[Jason]

Hey, does anyone know when this bug is going to be fixed and the FIND-BAR will auto-hide itself?

Comment 89

[Jason]

What's the Target-Milestone?

Comment 90

[B.J. Herbison]

(In reply to Jason from comment #88)
> Hey, does anyone know when this bug is going to be fixed and the FIND-BAR
> will auto-hide itself?

Hopefully not until 1) user studies have been done on find bar usage so the proposed change can be based on data, and 2) alternatives to address the use cases mentioned in bug 634454 have been developed.

When the find bar started closing many of us thought it was a bug because we use the find bar between tabs.

Comment 91

[Jason]

@BJ Herbison

None of the points you bring up in Bug 634454 are valid points. 

Auto-hiding the FIND BAR does not remove your ability to (quoting from your bug-report): "regularly search for text on a page and want to search for the same text again after the page reloads, and also often search for text on one tab and then the same text on another tab."

Please read Lindsey's post above. She disproves the claims you make in your bug-report. That is, you can do all the things you want even if the FIND BAR auto-hides. Meanwhile the rest of us are all suffering with an always visible FIND BAR.

Comment 92

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Just make "Auto-hide" option near "Match case" like I said here https://bugzilla.mozilla.org/show_bug.cgi?id=628179#c82

Comment 93

[Jason]

Wat's the point of even having an option? None of the "problems" that Bug 634454 speaks of are valid. Auto-hiding the FIND BAR does not prevent users from doing any of the things mentioned in the 634454 bug report.

So far, no one has presented a good reason for NOT auto-hiding the FIND BAR.

Comment 94

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Only for your point of view...

I stated some good arguments in comment #82 to do an option if auto-hiding become default behavior for Firefox

Comment 95

[Finn Bryant]

FYI, the original intention of this bug (at least from some parties, though not all) was to improve UI consistency by making everything below the tab bar tab specific, that would involve changing the behavior more, by removing the ability to remember searches between tabs. The idea you are discussing is different, that is why all the arguments made are suddenly "invalid".

Personally, I still think there should be a timer. If instead of disappearing on any navigation, we have it only disappear if it hasn't been used for 30 seconds on navigation, that would protect almost all legitimate uses *and* solve your problems. As for why, not everyone uses shortcuts (in fact, the majority don't, I think) and even those that do could assume that F3 only works when the bar is visible. It could be *really* annoying for a non technical user who has to go through the menu each time they switch back and forth between the 2 tabs they are checking.

As a use case,

Person A does a search in tab 1, then switches to tab 2 and does the search again, find bar would remain throughout. Then they switch to and read tab c for a bit, the 30 second timer runs out, the next time they change tab or click a link, the bar disappears.

It still waits for navigation to avoid distracting people by disappearing seemingly at random. It does mean that you have to accept the lost "screen real estate" for 30 seconds, but I think the issue people have isn't the short term annoyance, but the fact it lasts indefinitely.

This option shouldn't cost much extra in development, its the exact same suggestion apart from the timer, which would be started or reset on any use of ctrl-f, f3 or clicking anything in the find bar. It should probably be disabled if the current tab has been highlighted by find, as the user will probably want to leave things as they are.

The feature has more chance of being included if consensus is reached, and I can't see why anyone would dislike this solution.

That all said, this is probably not the best place to discuss it...

Comment 96

[Jason]

I think a Timer is a terrible idea.

The FIND BAR should simply hide itself when the user navigates to a new tab or clicks a link. 

Finn Bryant, 

Let us assume the FIND BAR auto-hides like I want:  if Person A does a search in tab 1, then switches to tab 2 (which causes the FIND BAR to auto-hide) and does the search again in tab 2 (e.g., by pressing F3 or Ctrl+G) = the FIND BAR automatically displays itself again with the writing from the pervious tab's search.

The FIND BAR auto-hiding when a user goes to a new tab or clicks a link is NOT "disappearing seemingly at random." The act of navigating causes the FIND BAR to auto-hide. But the user can still easily perform the same search by pressing F3 or Ctrl+G. The previous search is also not forgotten by the FIND BAR (it still display what was written). 

What is gained by NOT hiding the Find Bar when navigating to a new tab or clicking a link?

Comment 97

[Jason]

Timer = terrible idea was too strong a statement. I just meant to say that I think it would add complexity to the code that just isn't needed.

Comment 98

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

@ Finn Bryant - agreed with Jason, timer is a bad idea and can cause annoyance for users

(In reply to Jason from comment #96)
> The FIND BAR should simply hide itself when the user navigates to a new tab
> or clicks a link. 
I can agreed only when patch for this bug will implant also option to turn it off, because not everyone will like that idea.

(In reply to Jason from comment #96)
> What is gained by NOT hiding the Find Bar when navigating to a new tab or
> clicking a link?

Multitab search with highlighting all results will be completely unusable...
Like all things I posted in comment #82 ...

Just example of how I search with findbar.
Example:
I type 'unsolved problems in physics' in google
I open 20 interesting sites, looking on site description first
I open findbar and type 'problem', next I click 'Highlight all'
Using CTRL+TAB, I can go to other tabs and simply click 'Highlight all' to search active typed phrase.

It's saves my time a lot for using search and I'm glad that Firefox have this feature.

I don't understand why you Jason want persuade only your idea of auto-hiding and not creating option in findbar like "Auto-hide" by default disabled or some settings in about:config (but it's a bad idea only for geeks, not normal users). Please think about other users too. ;)

Comment 99

[Finn Bryant]

Thanks for the comments. Its a shame you dont agree...

@Jason, is code complexity the only issue you have with it? As I mentioned, a timer shouldn't really add that much complexity, and otherwise it would function exactly as your suggestion (eg, if the timer was set to 0, the result would be functionally identical).

@Virtual_ManPL timer is a bad idea and can cause annoyance for users

Annoyance? I assume that you mean it would cause extra annoyance beyond Jason's preferred solution? I could see that if it was just a timer, and the find bar disappeared when the screen wasn't already being changed due to navigation, but if it waits for navigation, where could annoyance come from (beyond it disappearing, which is hopefully less of an issue after 30 seconds since they have probably finished using it). Also note that I intended that highlighted search would disable the timer whilst on that page, the find bar would remain until you navigate, removing the highlights/looking at a non=highlighted tab.

the find bar disappearing will cause annoyance for users no matter what we do (as discussed in my above comment, I wont bother copying that paragraph here), it not disappearing will also cause annoyance (for some of the same users, perhaps mostly for a different set of users, that obviously includes Jason), I'm just trying to find the point at which the total annoyance of both groups is lowest.

But hey, if you both still disagree, ill let the matter rest, as long as the preference Virtual_ManPL is after is implemented i can live with things.

Comment 100

[Jason]

@Virtual_ManPL

Your example of how you do searches wouldn't require an always showing FIND bar if Firefox by default "Hightlighted All". Performing the search how you example still requires the user to put focus onto the FIND bar before it can be interacted with. So technically the only reason you want it always showing is so you don't have to reveal it before clicking on it. Hence if Firefox had better design you wouldn't have to reveal it because the software would either default to "Highlight All" like Google Chrome does or it would automatically resort to showing "Hightlight All" because you selected this in another Tab. So all you'd have to do on a new tab is press F3 and all would be highlighted regardless of whether the FIND bar is showing or not.

Regardless, why doesn't Mozilla simply add a setting to about:config = AutoHide FIND Bar (Yes/No)?

Problem solved.

God, I WISH they would fix this.

Comment 103

[Doug Turner (:dougt)]

pcwalton, are you working on this?  if not, let see if we can get one of the FF engineers to look at it.

Comment 104

[Jared Wein [:jaws] (please needinfo? me)]

Adding Chris Lee (:cleer) to this bug since he's been working on improving our find-in-page.

Comment 105

[Patrick Walton (:pcwalton)]

(In reply to Doug Turner (:dougt) from comment #103)
> pcwalton, are you working on this?  if not, let see if we can get one of the
> FF engineers to look at it.

Not working on it right now.

Comment 106

[Peter Bengtsson [:peterbe]]

I would just like to add my light weight opinion to this:

1. I agree with Jason. The times I need to do the same find in multiple tabs exists but is very rare in comparison to the noise reduction of having it auto-hide

2. A timer (e.g. 30 seconds) would be confusing.

3. If it was an option in about:config I would probably never bother changing it.

Comment 107

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Why would we hide option in about:config, when near "Match case" there is a free space?
Who would know about this hidden preference? Probably no1... ;p
Make life easier, not harder by searching in net how to change it.

Comment 109

[Dão Gottwald [:dao]]

Bug 537013 took care of the tab switching part of this bug.

Comment 110

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 5 duplicates, 16 votes and 59 CCs.
:mossop, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 111

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.