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 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.

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

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

Comment on attachment 506283 [details] [diff] [review] patch Switching review to dolske since I suspect Gavin is overloaded.

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

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.

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 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

Patch version 2 fixes the issue. Review requested.

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?)

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

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.

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.

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

Patch version 5 fixes indentation.

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.

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.

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.

(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.

(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?

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 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.

(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.

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

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.

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

(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.

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

(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

(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.

(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.

(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

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

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

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?

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?

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.

Dao: what should this bug's summary say? /be

(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

(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.

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

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

(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

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

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

- 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.

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

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

(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 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();

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 :(

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

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?

Patch version 9 makes the suggested changes.

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...

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

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).

(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.

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

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

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

(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.

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

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

yep.

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

(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.

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 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.

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.

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...

(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

(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.

(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 on attachment 515703 [details] [diff] [review] backout patch Removing approval flag. Backout happened.

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.

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!

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?

(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.

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

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!

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

What's the Target-Milestone?

(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.

@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.

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

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.

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

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...

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?

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.

@ 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. ;)

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.

@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.

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

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

(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.

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.

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.

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