Closed Bug 634454 Opened 13 years ago Closed 13 years ago

The Find bar at the bottom of the page keeps going away

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: bj, Assigned: faaborg)

References

(Blocks 1 open bug)

Details

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0b12pre) Gecko/20110215 Firefox/4.0b12pre
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b12pre) Gecko/20110215 Firefox/4.0b12pre

In the last couple of days the search bar in Minefield keeps closing. It closes when a page load happens and when I switch tabs.

Reproducible: Always

Steps to Reproduce:
1. Open the search bar with control-F.
2. Switch tabs, press F5 to reload, follow a link, or submit a form.

Actual Results:  
The search bar closes.

Expected Results:  
The search bar stays open.
OS: Linux → All
Hardware: x86_64 → All
Version: unspecified → Trunk
I think this is an intentional change, see bug 628179.
Reviewing bug 628179 the only justification I see is

> I think in almost all circumstances the user wants the find bar to go away once navigation happens.

and a few people support the change (before they have a chance to actually play with the modified version).

I, on the other hand, think that the user doesn't want the find bar to go away once navigation happens. I 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. This change has been a real annoyance for me.

If there's more basis to the change other than someone's opinion that the change is good I would like to see it.

Is anyone doing user interaction studies on Firefox? Could this issue be investigated?
We do have a heat map study and it shows no click traffic near the bottom. Can you explain your use case? I literally never did such a global search. Its pretty easy to add a feature to make the find bar sticky (extension or a check box). UX's current plan is to make the findbar state per tab and then keep it open per tab across navigation (if I understood them correctly, take this with a grain of salt).
(In reply to comment #3)
> We do have a heat map study and it shows no click traffic near the bottom.

The first thing that implies to me is that bug 628179 probably won't have a major benefit even if the basis for the change is correct. Does the heat map keep track of coordinates based on the top of the window? If so, variations in window size would make it hard to identify bottom of page activity.

But even if there was evidence in the heat map, it wouldn't distinguish between cases where 628179 was useful and where it was annoying,

> Can
> you explain your use case? I literally never did such a global search.

That's a problem with changing Firefox based on a small sample of users -- it is a general tool used in many different ways. While the change hasn't affected you, it's annoyed me several times a day.

A specific use case for keeping the search bar across page redraws: As part of my purchase process on eBay I "watch" items I might like to bid on and add user notes about details I want to research before I bid. When I research I search for the word "check" in my notes and update my notes with the result. When I decide against bidding on some items I delete them from my watch list, when the page redraws after the delete the search box has gone away.

Even if the delete form submit didn't clear the search box, my research usually involves looking at the item details opened in another tab (and often pulling up other web pages for more information). This tab switching closes the search box.

My most common use case for searching for the same term on multiple tabs is also research for online purchases. To compare two items, or the inventory of two vendors, I will search for a term on one page and then the other to compare the details or inventory for a particular area. I don't want a list of all uses of the term (like the "search all tabs" extension), I just want to compare the context of the search term on two or more pages.

> Its
> pretty easy to add a feature to make the find bar sticky (extension or a check
> box). UX's current plan is to make the findbar state per tab and then keep it
> open per tab across navigation (if I understood them correctly, take this with
> a grain of salt).

That would be an improvement. If that is the plan it seems unfortunate that the chosen path was to take away a feature only to add part of it back in a future release. That doesn't seem like an approach designed to make users happy.
B.J.,

you have my full support.
FF has never been as annoying as now. This retriggering of the Findbar (that's what I'd call it) is a PITA.
I'd even _avoid_ to change tabs too frequently now, since I'll always have to press CTRL-F again. And again...and again...

Back to beta 10, which was with this major annoyance.
Meh, what a long post, I overlooked the gist of it.

Yes, I agree, please make the Findbar sticky (optionally) so we can get rid of this behavior. 
Thank you very much in advance for consideration.
Reading through bug 628179 was a pain. I overflew parts of it.

The "not closing on subdomains" part hasn't been implemented yet(20110221), as it seems.

I'm not in favor of the current behavior. I will welcome a per tab Findbar behavior, but until this has been coded, the behavior of FF4 should be reverted to the old FF3.6 one. I stated my reasons in an post here http://forums.mozillazine.org/viewtopic.php?f=23&t=1961093&p=10447367#p10447367
but I will restate them here as short as possible.

The usecase (no1) the new behavior has been optimized for is the following:
A user opens a text filled page (i.e. bugzilla bug report) and wants to search for a keyword. The user opens the Findbar, finds what she/he (I cut the she from now on, I'm sorry.) searched for, forgets about the Findbar, it closes itself. Flawless service.

But there are other important usecases, too:
1. Broad search through several tabs.
2. Depth search following several links.

Example broad search usecase (no2):
A user starts an investigation on a search engine and opens several promising hits in several tabs. He wants to use the Findbar on each/most/some(3+) of them. Each time he changes the tab focus, the bar closes itself and he has to reopen it. (Let's keep quicksearch out of this for a moment. I'll explain later why.) It's not that hard to imaging this might happen 3+-7 times. The user should be annoyed at this point.
It's rather save to say, the user will almost never reopen the bar a eighth time. Somewhere the maintains of the bar became more a burden than the Findbar itself is useful as a tool. It's easier to overfly the pages with the naked eye.

Example depth search usecase (no3):
The user finds interest in a certain topic, which is accompanied by a keyword. He navigates through several ontopic pages by following the next most promising link each time (,which itself doesn't have to link to a subdomain of the current page) and wants to use the Findbar with the keyword to gain an overview of the new page. The Findbar closes always (/in the advanced version it closes in many cases and in some cases (subdomains) not). This should annoy the user, too.

As for quicksearch. I'm using the Findbar quite often and still didn't know about the F3/ctrl+g shortcut a few days ago, because there is no "find next" item in a menu. Most users aren't knowing about it either as they aren't using shortcuts. Many users purely navigate through the UI by mouse clicks. Reopening the Findbar per mouse becomes a special pain.

Users, who are casually using the Findbar (usecase no1), are fine, until they want to use it in the other ways (usecase no2, no3). No2 and 3 aren't too far fetched. Even a slightly advanced user should be able to come up with them as browsing strategy. 

Advanced users, who are using No2 and No3 more often will be annoyed with no end, until they learn about the quicksearch option.

A correcting add-on might be installed by advanced users, but not by casual Findbar users, who might get annoy by the new behavior anytime.

My conclusion: I, myself, forgot to close the Findbar several times, but I knew it was my fault. >I< used it an >I< didn't put it back. Almost no one should get annoyed by the old behavior. It's a given, as it has been on long term testing. On the other hand the good, the new behavior does, won't be noticed by the casual user, for whom it has been implemented, and it will yield a lot annoyance for advance Findbar users, who actually using this tool.
The old behavior + timer, like purposed in bug 628179 #23, is the best solution, until a real tab oriented code has been implemented. Experiment with the new behavior in the nightlies all you want, but I beg you keep it out of the betas and the main release. (about:config switch would be fine.)

A heatmap is fine, but shouldn't be able to keep up with this arguments.
Hey, what's the deal with all your mega-long posts here guys ? :)
I couldn't be **** to read it all thru...=p

My use-case is a mere 10 liner:
You're a DJ looking for a particular record on Musicstack (record seller platform) that you can only faintly remember by some criteria. But because the Musicstack search abilities are still those of a site made 15 years ago---so to say, extremely poor---you'll maybe have to face the situation of having to sift thru 10 pages.
Now you use the Findbar to skip through irrelevant entries, memorize relevant entries (currently 3) by "parking" each of them in a separate tab: 
So you have your MAIN TAB (where all the action happens) and the 3 auxiliary tabs where the entries "to be deep-checked" reside.

So each time you return back to MAIN TAB, you'll have to reopen the Findbar, because it's gone.
Surely you won't care about the Findbar being active or inactive in the aux tabs, but you definitely DO need it permanently active in the MAIN TAB.
Please, reconsider to apply the previous behavior, it's too annoying press CTRL+F
every time I come back to the page where I have to search text.
The current behavior is good only when you have to search only one time, but this is not the normal case in particular when you search e.g. code from patches to files or when you have a document that you have to work on.

At least make the behavior customizable. I don't want to think that every good FF's feature have to be deleted because the average user (or maybe the newbie) doesn't use it. The list of these features is getting bigger day by day, and what is worse is that you can't restore nothing, you can't choose anymore what you want. The average user chooses for everybody.
Blocks: 628179
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: The search bar at the bottom of the page keeps going away → The Find bar at the bottom of the page keeps going away
Andreas, as mentioned in bug 628179, the heat map doesn't and isn't supposed to tell you anything about the find bar. Please stop citing it. :/
Have to add my voice to this one.  The change the other week that automatically removes (and clears out) the Find bar on a per page basis (it clears not only per tab but per page load) is perhaps the single most annoying change I've seen applied to an application since the Office 2007 redesign - and I'm still on 2003 because of that...

The use cases above pretty much cover it.  One additional use case is in blog reading.  I keep a find bar open in my blog reading window with the term '[new]', which speeds my reading significantly.  Since I track several blogs - and several diaries within each blog - while reading, and they all use the same string to flag new items, I always want that string up and ready to run...

Put it back, or make it a configurable item - and I don't mean buried in the about:config page.  This is a real annoyance to several classes of users.
Clearing the find bar on navigation isn't the ideal way for us to get it to not stick around.  But it was easy, and it quickly solves the greater problem of our overall UI footprint.

Getting the find bar to be per tab should help a lot, and we can also help users who plan on doing the same search across multiple tabs a bit based on how we implement the behavior.

For instance, if we retain the find bar in cases where it is displayed and the user command/control-clicks a link, that will cover some of the cases where they may intend to do the same find operation again.  We probably want to use the same metric for deciding if we clear the text of the search bar (which is also meant to be per tab).
Alex, I find your comment infuriating. You seem to be coming from the position that reducing space used is more important that anything, and that everyone knew that sharing the find bar between tabs was a bug. As the comments above show, some of us don't.

Yes, I agree Firefox shouldn't take up unnecessary space and I have removed controls I don't use that in mind. I also want more space in my car when I'm driving and car designers keep trying to move things around to provide more usable space -- but they don't take away the steering wheel to give more space to the driver.

Do you have any studies about the Find Bar use across tabs? Of the people who regularly use the Find Bar, what portion use it across tabs? What portion of users use the Find Bar once, leave it open and then never use it again?

I other words, do you have any idea how many people you are helping and how many you are annoying?
I encouraged Alex to comment here to suggest how this bug might be fixed. Calling his comments infuriating is not productive.

Most people in my 7 years of Firefox experience have find bars stuck uselessly tying up space, with very stale text-to-find, hanging around for the life of the affected windows.

Some users sometimes want find bars to stick around across navigation. The CD shopping site where you want to find a particular name while navigating a list of CDs is compelling.

Finding a way to satisfy those users (a minority by any count in my experience) while not leaving everyone who ever finds with a stuck bar is what this bug is about. I'm sorry we regressed the find bar for you, for some sites. We're trying to make progress without first coming up with the perfect solution.

I do not believe we have find bar studies (Alex, correct me if I'm wrong). We can use testpilot to study this but it's not going to happen before Firefox 4 ships, and we're not going to reverse the incremental win for most users. If we're wrong and most users do want the find bar to persist across navigations, then we made a mistake. I doubt it.

Working on this bug without fighting or flaming is better than rehashing your preferred outcome in a short-term win/lose trade-off. Alex's comment reached for a win-win design. It seems to me you want to win and make all the users who put up with uselessly stuck find bars "lose".

That is the kind of zero-sum game we don't want to play, even as we make imperfect incremental progress. The way out is along the lines Alex suggested: per-tab find bar, better persisting logic based on how the tab was opened, and other clues we haven't thought of yet.

To discuss design ideas here is not infuriating, it's necessary to fix the bug. If you can't keep your temper, don't comment. If an add-on to restore the stuck find bar behavior would help, I can try to find someone to build one.

/be
BTW, while the find bar closes on navigation, the text-to-find is preserved and you can cmd-G (Mac) to find again. Does this help?

/be
(In reply to comment #14)
> I encouraged Alex to comment here to suggest how this bug might be fixed.
> Calling his comments infuriating is not productive.

I'm sorry I annoyed you and Alex.

Here's why I was annoyed by his post:

1) It admits the approach wasn't the best, but was done anyway.

2) It talks about a "greater problem" (greater than what?) without
   any data that this change significantly helps the problem.

3) It talks about maybe making some future changes, which don't address
   the use cases I and others have talked about.

4) I didn't see the "win-win design" you saw in Alex's comments, probably
   because I didn't see a specific suggestion or anything I would
   consider a win for me (because it didn't address my use cases).


> That is the kind of zero-sum game we don't want to play, even as we make
> imperfect incremental progress.

How do you know this change was "progress" without studies?


> To discuss design ideas here is not infuriating, it's necessary to fix the bug.
> If you can't keep your temper, don't comment.

I didn't lose my temper, I didn't rant, I didn't call names.

I did ask if there were studies about usage, trying to get a productive conversation going. I first asked for that in comment 2. There apparently aren't any, just everyone with their own anecdotes. I personally have not seen many people with "stuck" find bars -- the people I've seen either use the bar regularly or don't have it visible (where "don't have it visible" means either "don't use it at all" or "close it after use").


> If an add-on to restore the stuck
> find bar behavior would help, I can try to find someone to build one.

Yes, that would be very helpful for the people who follow this bug. (Not so much for people who are annoyed with the change and aren't in the habit of searching buzilla or extensions whenever a change annoys them, but neither of us knows how many people will fall in that category.)


I do appreciate the tone of your comment, and I would like to find better solutions.

Here are some suggestions:

1) Mentioned somewhere above (and I think in other places): Close the find bar based on a timer. If you use it every minute it stays around, otherwise it get hidden.

I think a timer of one minute would mean the bar would almost always be around when regular users want it and be closed almost all the time for occasional users. (But a study would be useful.)

2) Put the find bar at the top, just under the URL bar. Advantage 1: It's closer to the default location of the tab bar for people who switch tabs and want to find the same text. Advantage 2: People who use it once and are done will see that it is still around when they view another page and can easily close it so it doesn't become stale.


> BTW, while the find bar closes on navigation, the text-to-find is preserved and
> you can cmd-G (Mac) to find again. Does this help?

It is better than having the text go away, but it means switching from mouse/touchpad (for switching tabs and clicking "find next") to keyboard and back.
The "best is the enemy of the good" cliché is not always helpful. IMO it applies here, but for those of you on the "other side" it's no help.

I'll drop it, I brought it up to emphasize the idea of incremental paths toward "best". We have in the past left UI elements, especially the find bar, untouched for many releases, based on wanting a more-perfect design.

We have also had some ambitious designs not fully realized for a given release that left no one happy. So I agree it's tricky to make more-good-on-each-release path-dependent progress and not get stuck in a corner and have to back up. Yet I think we must try, especially now with quarterly major releases.

> How do you know this change was "progress" without studies?

We don't, and even usability studies can be less conclusive than you'd like due to confounding variables, volunteer effect, etc. But we should definitely do more and I believe the plan is to use testpilot, which has a large-enough user cohort now (cc'ing Jono).

In this case we went with a judgment call among the UX and Firefox people, based on a patch in hand. You're right that data would be strictly better, even if not always conclusive.

An idea for this bug: with the find bar per-tab, could we detect (scraping or semantic markup) pages that are 1-10 or 50 hits on a site like amazon, and leave the find bar up if it were brought up during any page load in the series? Such pages often do have link tags and other semantic markup.

/be
> semantic markup) pages that are 1-10 or 50 hits on a site like amazon, and

Typo: "1-10 of 50", not "or".

/be
Assignee: nobody → faaborg
Among the proposals in comment 16, I like (1) (a timer to auto-close) although there may be some unforeseen scenario in which that bites back.

(2) (find bar at top) I see in Chrome and (earlier) Safari, which I use often. I find it disruptive (it pushes the content down instead of clipping in Safari; in Chrome it's misshapen and on the right) compared to find bar at bottom. While putting it at top could call attention to it enough to get users to manually close it, why make the user work more if we can automate and be less obtrusive?

/be
I'd already know the optimum solution for me.

Some of you guys know well that "pinning" technique used by Solaris as well as the CDE on AIX?
You can have multiple desktops, and "pin" a specific window to one or even all desktops.

That's where we could come from: *optionally* "pin" a Findbar to a tab by means of a small drawing pin icon.

- If the pin is in "pinned" status, the Findbar will also appear again if you switch to another tab and then back to the original tab.
- If the pin is in "pulled out" status, the Findbar will be volatile, i. e. when you do the tab switch described above, the tab will be gone next time.

Code-wise, you'd merely have to maintain an array of booleans USER_PINNED[i] = true/false where i is the tab index.

If you want it even more sophisticated, disable/enable pinning of Findbars in the regular (!!) options (no, you'd better not conceal it somewhere in the depths of about:config, thanks)
If pinning is disabled, the browser will work the same way as current b12/b13 betas.
Sorry, I mistyped something.

"when you do the tab switch described above, the tab will be gone next time."

Should've been "The Findbar will be gone." Sorry.
(In reply to comment #17)
> An idea for this bug: with the find bar per-tab, could we detect (scraping or
> semantic markup) pages that are 1-10 or 50 hits on a site like amazon, and
> leave the find bar up if it were brought up during any page load in the series?
> Such pages often do have link tags and other semantic markup.

I'd worry that people wouldn't understand when the find bar stayed and when it vanished (even if the scraper was perfect),

Currently the links in Google search results all point to google.com and redirect so Google can learn from what people select -- would the scraper keep the Find Bar when following those links?
Some workaround.

This code toggle findbar between sticky-visible and normal state:

if (gFindBar.style.display == "-moz-box") {
	gFindBar.style.display = "";
}
else {
	gFindBar.style.display = "-moz-box";
}

However in sticky-visible state Esc-shortcut and close-button don't work. In normal state all shortcuts (Ctrl-F and Esc) and close-button do work the way it should be.

You can install "Custom Buttons" extension (https://addons.mozilla.org/firefox/addon/custom-buttons/) and create a button with the code or simply open this URL after the installation:

custombutton://%3C%3Fxml%20version%3D%221.0%22%20encoding%3D%22UTF-8%22%3F%3E%0D%0A%3Ccustombutton%20xmlns%3Acb%3D%22http%3A//xsms.nm.ru/custombuttons/%22%3E%0A%20%20%3Cname%3EToggle%20Findbar%3C/name%3E%0A%20%20%3Cimage%3E%3C%21%5BCDATA%5Bdata%3Aimage/png%3Bbase64%2CiVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAACXBIWXMAAAsTAAALEwEAmpwYAAAABGdBTUEAALGOfPtRkwAAACBjSFJNAAB6JQAAgIMAAPn/AACA6QAAdTAAAOpgAAA6mAAAF2+SX8VGAAAAd0lEQVR42mL8//8/AyWAiYFCQLEBLLgkvGu2MTAwMAgyMDCsYmBgcGFgYHjPwMDgurXF6ywpLpgJ1VwBNUyJVC8YQ+lZDAwMjAwMDKtJMeAdko3voC4gKRCFoP5GZ5MVC4KURqPg4E1IhGIB5vQzuLzBOPQzE2AA8kwVK2p+S8gAAAAASUVORK5CYII%3D%5D%5D%3E%3C/image%3E%0A%20%20%3Cmode%3E0%3C/mode%3E%0A%20%20%3Cinitcode%3E%3C%21%5BCDATA%5B/*Initialization%20Code*/%5D%5D%3E%3C/initcode%3E%0A%20%20%3Ccode%3E%3C%21%5BCDATA%5Bif%20%28gFindBar.style.display%20%3D%3D%20%22-moz-box%22%29%20%7B%0A%09gFindBar.style.display%20%3D%20%22%22%3B%0A%7D%0Aelse%20%7B%0A%09gFindBar.style.display%20%3D%20%22-moz-box%22%3B%0A%7D%0A%5D%5D%3E%3C/code%3E%0A%20%20%3Caccelkey%3E%3C%21%5BCDATA%5B%5D%5D%3E%3C/accelkey%3E%0A%20%20%3Chelp%3E%3C%21%5BCDATA%5B%5D%5D%3E%3C/help%3E%0A%20%20%3Cattributes/%3E%0A%3C/custombutton%3E
So, it will be in the shipping release. You should keep in mind, that most people, who don't like this change, won't notice it at once and will most likely not find a place to vote their opinions. (Will Feedback be installed by default?) Critics might be spread thin, at first.

In https://bugzilla.mozilla.org/show_bug.cgi?id=634454#c13 sharing the Findbar over tabs is called a bug. Know that it's gone, I realized, it was a feature for me. Axing features will always call people into the arena. I hope enough.

The concept of incremental paths toward the best possible solution is known to me. But while the developers in favor of this change might see it in another way, I see, that this path leads through a valley of darkness. (Too theatrical?) I fear, the benefits of this change have been overestimated and the number of people potentially disliking it has been underestimated. The outcome of this bold step is not clear and I personally think it's to risky. The Findbar should be improved, if possible. The current change in behavior is a valid step on this path, but it's too incomplete and very annoying to an unknown number of people ,I estimate higher than you, to be shipped with a main release. It should have stayed a bit longer in Mozilla labs. 

But the team made up their minds. I stated my reasons against it. That has to be enough.

Regarding an add-on:
The timer in combination with the old behavior is the best short term solution, as it yields a simple and practical solution for the forgotten Findbar syndrome, until a concept for a tab-oriented arrives. Its only drawback is, that the bar suddenly disappears form sight after a given time. But as overlooking the bar is the root of this problem...
1min would be too short, as the user might be distracted or stops the search for some time to read a passage of a page. A longer period of time is possible as long as the bar closes. Even 30min should be still fine. 10min might be the optimum.

A pin to switch between the new and old behavior is a nice last minute idea for the RC.

PS: Sorry my comment got that long again.
(In reply to comment #23)
> Some workaround.

Thank you, that's a good start.

Custom Buttons is not supported for anything more recent than beta 8, but it seems to work. It's too bad the escape key doesn't work, I often used that to clear the Find Bar and move focus back to the page.
> It's too bad the escape key doesn't work.

You can bind any shortcut to the custom button (in button settings). It will toggle the state.
In search of a usable and acceptable solution:

* I like the idea either of a pin, or of adding a configuration option (under Tabs, perhaps?)
* I don't think a timeout is a good solution; people with sporadic surfing habits will inevitably wind up cursing when it goes away without their saying anything about it, and people who are exclusively using their browser will say it stays too long.
* I'll put up with an Add-on for now, but putting the change there pretty much relegates this issue to an unsupported status where it is more likely to languish and eventually become unusable; the lack of functionality caused by this change is IMHO much more annoying than something to be addressed as a plug-in.
* I don't think there is a single use case which applies to everyone which will allow some kind of "intelligent" decision making on whether or not to keep the find bar open.  But if you're determined to take control away from the user by not providing an easily accessible configuration option, then I'll provide the following "intelligence": for most cases, I think the Find bar is opened on a child page (i.e. on a tab opened from clicking a link), and the user will want the find bar up on all sibling pages.  (E.g. I search in eBay for an item, control-click on multiple items to open them all in tabs, then I'll want to do a Find on each of those pages for the same term, without having opened the Find bar on the parent page).

Finally, a rant, which you are free to ignore if it is too blunt...  This is not the first time that someone doing Mozilla development has made a change that seems more convenient for them but in fact breaks other peoples' use of the product.  (See, e.g. Bug #153344, wherein someone decided to use the same keycode for KP plus and minus as regular keyboard equals and minus, thereby completely breaking any comprehensive keydown/keyup processing of those keys...)  Could we *please* get some kind of review where other people's uses are considered before we go ahead with functional changes?
Personally, I can settle for:
a) the find bar to be sticky as it was
b) there's a config option to change it back
c) if you must continue with the "user's screen estate is occupied by a couple of pixels at the bottom and we shouldn't let this happen" (which IMHO, doesn't make sense to me, if the user doesn't notice/care that the bar occupying those pixels is still there, then he really isn't fussed about it; if he does notice and Escape or a click can close it); then at least make it sticky per tab, right now:
- even refreshing the page makes it disappear
- if I start searching before the page fully loads, when the loading finishes the bar is gone??

(just my humble 0.02€).
Comment 28
> if I start searching before the page fully loads, when the loading finishes
the bar is gone??

I can't verify that. Post the address of an example page. And if you're sure that it's a general problem, create an own bug.
(In reply to comment #29)
> Comment 28
> > if I start searching before the page fully loads, when the loading finishes
> the bar is gone??
> 
> I can't verify that. Post the address of an example page. And if you're sure
> that it's a general problem, create an own bug.

I can't reproduce now either, sorry about the false alarm. (but the bar does disappear on refreshing the page).
No problem. Striking alert is a good thing. Bug 634440 seems to have addressed this branch problem already. Looks like it has been fixed in one of the latest nightly builds.
>  Bug 634440 seems to have addressed his branch problem already.
No. It is fixed by the back-out patch in bug 628179.
fixed by backing out bug 628179
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Nice. Can we please have this in textual form again what *actually* has been done/changed now and how the next nightlies are supposed to behave?

"We backed out bug id 987654" does not tell too much to the average user.
the average user shouldn't be looking for information in bugzilla. the nightlies will be out shortly, and you can test them out according to the behaviours you care about most.
(In reply to comment #31)
> No problem. Striking alert is a good thing. Bug 634440 seems to have addressed
> this branch problem already. Looks like it has been fixed in one of the latest
> nightly builds.

Yes, better now with latest nightly build; thanks.
>the average user shouldn't be looking for information in bugzilla. 

Yeah right, only the "elite" that always knows best what to put into Firefox should. Don't get me started on commenting further to this sort of attitude!

>the nightlies will be out shortly, and you can test them out according to the
>behaviours you care about most.

Well, I could have found out that bit myself.
But anyway, it's also nice to know the actual status in short BEFORE testing a build instead of having to look into the code for making some wild assumptions.
Please add functionality to, at least, Pin the find bar because some of us really need it to be open at all times. thank you!
> Please add functionality to, at least, Pin the find bar because some of us
> really need it to be open at all times.
It is the case in the latest nightlies.
Mozilla/5.0 (X11; Linux i686; rv:2.0) Gecko/20100101 Firefox/4.0

Verified issue and it's no longer present.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.