417346 - Make find bar less persistant

Status: RESOLVED FIXED

(Camino Graveyard :: General, defect)

Description

[Stuart Morgan]

I often realize that I have a find bar sitting at the bottom of my window that's not relevant anymore. I think we should consider moving to the Safari model, where the bar is tab-specific, and hides automatically when leaving the page.

It's not critical for 1.6; I just wanted to file to get it on the radar, and see what other's impressions are.

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

"...at which point it's also hard to close from the keyboard." ;)

I'm pretty good about noticing something's eating my content area when I've Cmd-F for some reason, and then must mouse back in to close it, so for that reason alone I'm in favor.  Well, and the proposed behavior just seems saner in general.

Comment 2

[Stuart Morgan]

I have a patch for this, but it's tangled up with the patch for bug 408530, so I'll wait until that has landed to get a good diff to post. Pulling to 1.6 since it's done though.

Conveniently, the desired behavior is that of the popup blocker bar, so I have a lot of confidence that the hiding logic is all wired up correctly.

Comment 3

[Stuart Morgan]

Attachment: fix

This changes the behavior to match that of the popup block bar. It also fixes a leak of the view, and makes it so that it can't be opened for non-text content now that it's page-specific.

Comment 4

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 304283 [details] [diff] [review]
fix

sr=pink

as stuart and I discussed a few days ago, we should make a generic mechanism for hiding bars (popup blocker, find bar, etc) that are transient rather than hard-coding the mechanics of showing and hiding the individual bars all over the browser wrapper.

Comment 5

[Stuart Morgan]

Landed on trunk and MOZILLA_1_8_BRANCH.

Bug 418626 filed as a follow-up for comment 4.

Comment 6

[Leander Koornneef]

Hi guys,

I've been tracking Camino trunk recently and was pleased to discover that this
findbar persistence issues is fixed (thanks!).

However, since updating to 2008-02-21-00-trunk, I'm experiencing problems with the findbar's usability. Apparently, this change introduced some sort of timeout that resets the findbar search content, after which a new search is started upon further input. The timeout value seems to be somewhere around 0.5 seconds, which strikes me as too short, because you have to type pretty fscking fast for it to work. I'm having great difficulty to do any searches using search terms longer than 4 characters.

Also, when hitting this timeout/reset, the current search term gets selected, so you can't extend the search term without overwriting it, unless you first deselect the existing term. Maybe the value for this timeout could be made into a user preference? 

Comment 7

[Stuart Morgan]

Please file new issues as new bugs; this bug was about persistence of the find bar, and is fixed.

Comment 8

[Leander Koornneef]

Ok: Bug 419051