248955 - search box should be tab-specific (content should not persist when switching tabs)

Status: NEW

(Firefox :: Search, enhancement, P5)

Description

[Charles Fry]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040614 Firefox/0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040614 Firefox/0.8

I may be spoiled as an occasional Safari user, but I wish that the Search box's
history were specific to each tab. Amoung other things, this makes it easy to
clear the Search box (open a new tab), which is important under Linux as it
allows for simple pasting of new search text without the problematic selection
of the old search text.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

[Aaron Sloman]

I strongly support this proposal. I frequently start a new tab in firefox
because I wish to do a new search (usually in google). The new tab always comes
up with a clear box for a url, which is sensible, but it does not start with a
clear search box. I don't understand the reason for this inconsistency.

I wonder if it is worth doing any kind of survey to find out how many people
actually welcome saving the previous search box contents when they start a new tab.

Aaron
===
www.cs.bham.ac.uk/~axs

Comment 2

[Aaron Sloman]

I have just noticed that the feature requested in this bug report (clear search
box when opening new tab) is already present when a new window is opened.

I suspect that the inconsistency in not extending this to opening a new tab, was
just an oversight and this should be easily fixed.

Aaron

Comment 3

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

Taking this. This is a valid RFE, although whether or not this is expected
behavior isn't very clear to me.

Comment 4

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

The problem with doing this is that the search widget (and the entire toolbar
for that matter) is per-window, not per-tab. It would be possible to do
something like the what is done for the location bar, although as I said above
I'm not sure that having tab-specific search boxes is expected behaviour.

Comment 5

[Martijn Wargers (dead)]

Well, I definetely like current Firefox's behavior, _not_ clearing search box
when switching tabs.
My favorite editor (editpad) also doesn't clear the search box when switching tabs.

Comment 6

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

I think this should be WONTFIX, the difficulty of implementation isn't offset by any real gain in usability, and I agree with Martijn's comment.

Comment 7

[Phil Ringnalda (:philor)]

I demo tabbed browsing by searching Google, opening a couple of results, then opening a new tab and doing the same search on Yahoo.

Also, to add to the complication of the code, I now have the search box in my own profile set to always open results in a new tab, so your clearing would have to depend on how the tab was opened, something ugly like passing a bool to addTab saying whether or not to clone the history attached to the opening browser. Yuck.

Comment 8

[Phil Ringnalda (:philor)]

*** Bug 315175 has been marked as a duplicate of this bug. ***

Comment 9

[Aaron Sloman]

A compromise option:
I have just noticed (for the first time!) that right button in the search
panel produces a menu that includes 'clear search history'. That can be
a bit drastic.

Adding one more option 'clear search' (or just 'clear') would meet the
need.

Of course not everyone will want to use this but the fact that some people cannot see the need is irrelevant to the fact that some people will find it
very useful very often (e.g. me).

Aaron
www.cs.bham.ac.uk/~axs

Comment 10

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

(In reply to comment #9)
> Adding one more option 'clear search' (or just 'clear') would meet the
> need.

There's already a "Delete" option in the context menu (for people who don't like using keyboards, apparently!). I think you've misunderstood what this bug is about.

Comment 11

[Aaron Sloman]

(In reply to comment #10)
> (In reply to comment #9)
> > Adding one more option 'clear search' (or just 'clear') would meet the
> > need.
> 
> There's already a "Delete" option in the context menu (for people who don't
> like using keyboards, apparently!).

Yes, but that does nothing (and is greyed out) if the search text has not been selected. I don't want to have to select the text because I can then lose a previous selection that I wish to paste in. So something to clear the text even if it has not been selected would meet the need. The 'delete' option might always be made available, and would certainly suit me, but that might confuse people who are used to using it only to operate on selected text. I assumed that  disabling it when the search text has not been selected was deliberate.

> I think you've misunderstood what this bug
> is about.

In what way?

It's true that the original bug report mentioned two issues
(a) cleared search panel makes it easy to paste in new search string
(b) having a separate history for each tab.

My solution would not serve (b) but I thought (b) was mentioned only as a means to (a).

But perhaps I am still missing something.

Aaron

Comment 12

[Charles Fry]

Having let so much time pass since I reported this, let me add a bit more history and further information to clarify my request:

1) Safari does include this functionality that the search box, like the location bar, is tab specific. I found it very useful there, inasmuch as I could have seperate search themes and search histories in different tabs.

One case in which this can be useful is when modifying the engine behind the search that is performed. For example, I would search for totally different things at Google as I would at CPAN or Amazon. Having them each in their own tab provides some additional organizational flexibility.

Perhaps this is not the behavior that everyone would like, but it strikes me as a reasonable configurable option. While I by no means expect Firefox to mimic all of Safari's good behavior, I think that the fact that Apple included this functionality is indicitive of the fact that it can be appealing/useful to many people. Some of you honestly sound like Internet Explorer defending the lack of tabs for as long as they could, because they just didn't understand how awesomly flexible they are. Sure, you have your habits, but if you want to get a feel of whether or not this functionality can be useful, go and use Safari for a while. Then at least you can make a more balanced judgement on the matter. :-)

2) As for the idea of being able to manually clear the search tab, that is a separate design decision, and probably ought to be split into a separate bug. That said, I'll comment on it here just the same. :-)

Rather than adding a menu option to clear the search bar, it would be easy to add a small X on the right side of it, that could be clicked on to clear the search bar. This is in fact what Safari does, and I find it to be rather convenient.

FWIW,
Charles

Comment 13

[Ashutosh Naik]

(In reply to comment #12)

> Rather than adding a menu option to clear the search bar, it would be easy to
> add a small X on the right side of it, that could be clicked on to clear the
> search bar. This is in fact what Safari does, and I find it to be rather
> convenient.

I Ack this. It would work great for me, if this change is merged into mainline.

-Ashutosh

Comment 14

[Aaron Sloman]

(In reply to comment #12)

> 2) As for the idea of being able to manually clear the search tab, that is a
> separate design decision, and probably ought to be split into a separate bug.

Apologies -- it was mentioned explicitly in the original bug report and I latched on to that as my main concern here.

> That said, I'll comment on it here just the same. :-)
> 
> Rather than adding a menu option to clear the search bar, it would be easy to
> add a small X on the right side of it, that could be clicked on to clear the
> search bar. This is in fact what Safari does, and I find it to be rather
> convenient.

That would meet my needs. The only reason I did not mention it is that I want the location panel and search panel both to be as wide as possible and adding an X (as on the tab bar) would lose about 6mm. But I could live with that. I would be happy to have the option to lose the Go button as I always just hit the 'Return' key.

Aaron

Comment 15

[tommyjb]

Opera also supports tab-specific search bar contents.

Comment 16

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

*** Bug 271656 has been marked as a duplicate of this bug. ***

Comment 17

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

*** Bug 317812 has been marked as a duplicate of this bug. ***

Comment 18

[Andrew Ramage]

Note that Opera _does_ have tab-specific search boxes.  Should Firefox implement this functionality ?

Comment 19

[Ryuichi KUBUKI]

*** Bug 271656 has been marked as a duplicate of this bug. ***

Comment 20

[Peter Kasting]

There are reasons for and against this, but the current behavior is by design rather than by accident.  Changing it depends on some architectural cleanup I'd like to make at some point, but I wasn't planning to change the behavior then, just make it _possible_.

I'm not WONTFIXing this because I'm not convinced it's a bad idea, but don't get your hopes up any time soon.

Comment 22

[Biju]

===  About:Config  ===

If this ever implemented please have config items for:-
  1. whether or not tab specific search
  2. clear or pre-populate search-box on new tab

Whether good or bad I am used to current behavior of seeing last search pre-populated. 
ie, I do Ctrl-K then Alt-Enter to do previous search again

Comment 23

[Micah Gersten]

Ubuntu Bug:
https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/306017

Comment 24

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Let's hear the opintion of the UX team. Alex, what do you think?

Comment 26

[Ria Klaassen (not reading all bugmail)]

This bug seems a mix of "search" and "find".

Comment 28

[Jason Spiro]

(In reply to comment #24)
> Let's hear the opinion of the UX team. Alex, what do you think?

At http://thread.gmane.org/gmane.comp.mozilla.ui/3535 Alex Faaborg agrees that
the idea in this RFE is a good idea.

He adds, "Persisting the search in the search bar actually ruined the birthday present my wife gave me this year (canon 7D!) when I sat down at her computer and went to do a google search, so I'm acutely familiar with the privacy concerns".

Comment 29

[David McRitchie]

I use the search bar for a scratch pad next the menus as well as for searching, I certainly want to be able to see it at all times from any tab without it changing whichever use I am using it for.   If I want to modify a search on a specific page, it was probably done with Google, and if it isn't the same as on the search bar, I will modify the search at the top of the Google search page.

Comment #24 and #28 are absurd use Private Browsing.

If I am doing several searches they would almost always be related to a previous search in some manner, even if to a different search engine.

Comment 30

[Alex Faaborg [:faaborg] (Firefox UX)]

>If I want to modify a search on a
>specific page, it was probably done with Google, and if it isn't the same as on
>the search bar, I will modify the search at the top of the Google search page.

It would be good if we synced those two up, I think limi is looking into this.

>I use the search bar for a scratch pad next the menus

that's absurd, use notepad or something :)

>If I am doing several searches they would almost always be related to a
>previous search in some manner, even if to a different search engine.

We might want to momentarily carry the search contents from one tab into a new tab, and clear on page load if the user uses the location bar.

I think overall it is much more likely that the contents of the user's search bar will be unrelated to what they are currently doing in Firefox, since we persist it indefinitely right now.

Comment 31

[Gregory Maxwell]

I was made aware of this bug through the paper cut presentation at http://www.scribd.com/doc/31643187/Firefox-4-Paper-Cuts-Alexander-Limi-Firefox-User-Experience

and I felt the urgent need to make a suggestion here before this bug results in yet another new paper cut.  A very common pattern for me is to open up a bunch of blank tabs and then fire off minor variants of a search in each.  E.g. "Mozilla video crash", "Mozillia video segfault", "Mozilla video vanishes". 

Making the search fully tab specific would seriously frustrate this totally reasonable use case.   At a minimum I'd urge that the tab specific search retain a common _history_ with the other tabs.  This way my user pattern would just gain an extra key-press.

Comment 32

[Aaron Sloman]

Although I supported this bug originally (search box should be tab-specific (content should not persist when switching tabs) I can see that there are enough valid reasons for keeping the current behaviour. So why not follow up the suggestion to add simple mechanism to clear the current search *without first selecting its contents* because that selection will overwrite something the user wants to paste into the box.

Typical scenario: I am reading something and find I want more information about XXXXX mentioned in the document. I select XXXXX (which is often an extended phrase, not just a word) then go to firefox and open a new tab. However I then find the search box includes old contents. I can delete the old contents by clicking in the box and repeatedly hitting a delete key, but that's just another contributor to RSI. I need a quick way to delete current contents leaving me free to paste in the new search string.

Currently I have to go to firefox, open new tab, select and delete current search string, go back to document, select new search string, come back to firefox, paste in new search string. I can't believe I am the only user who has wasted much effort over several years doing this!

So I would again endorse the suggestion in comment #12 "Rather than adding a menu option to clear the search bar, it would be easy to add a small X on the right side of it, that could be clicked on to clear the search bar." 

Failing that, a context menu option to clear the (unselected) text from search box would suffice. This would leave current behaviour for those who want it and save much time for people whose work or other activities often require the scenario I have described.

Comment 33

[David McRitchie]

Regards to c#12 and c#32 for clearing.  Much simpler is "Ctrl+K" then "Del"  will select place cursor at search bar, clear the search bar, and be ready to use.  Placing an "X" at the right just wastes space and creates more clutter, as did the "Go" button if it still exists.

Comment 35

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

Search bar should most definitely be tab-specific. This was intended to be fixed when we switched to tabs-on-top in Firefox 4, but wasn't.

Comment 37

[Adam]

Attachment: WIP v1: Initial tab-based searchbar.

The basics of it work.  Known concerns:

Default engine: Should the first-in-list engine be restored on a new browsing session/new window?  (Currently the selected engine upon startup will be the engine of the tab that was selected when the last session ended.)  

Session restore: Should the selected engine and last-search be restored with the tab?  

New tabs: What was suggested in comment 30 seems best, so the question is whether just to clear or if the engine should also be re-defaulted.  (Currently the new tab has the same data as the last-selected tab, without the mechanism of clearing on location change).

Comment 38

[Adam]

Attachment: WIP v2: Implements sessionstore, restore-to-default on locationbar edit

This iteration saves/restores the search data per tab across sessions.  That data is the engine, query, and whether the engine/query has been modified by the user.  That third piece of data is used for determining whether to reset the engine/query when the user manually navigates (via the location bar).

This patch implements that feature, but it be improved upon: certain actions don't reset that might be expected to (eg, clicking on a site in the New Tab page).

Opening background tabs will now use the search data from the opening tab.  When the tab is opened from a tab without an engine (eg, the Addons Manager), it just uses the default engine.

Comment 39

[Adam]

Attachment: WIP v3: Flag loads as "browsed to" for better control/coverage of persisting/resetting search

The goal for this version was to approximate the behavior described in Bug 565740, Comment 4.

This patch has the various URI loaders that should persist the search use |nsIWebNavigation::LOAD_FLAGS_BROWSED_TO|.  The flag indicates the load is organic to the current user activity.

That flag gets transformed in |nsDocShell| to an instance variable |mBrowsedTo|.  That's checked by callers to |nsIWebProgressListener::OnLocationChange|, so they can include the |LOCATION_CHANGE_BROWSED_TO| flag.  In turn, tabbrowser's listener will persist the search data (engine/value) if it hears that flag.

Load types accounted for:
1. Persists search:
  1. New (blank) tabs
  2. Search bar
  3. Content Link loads (current, tab, tabshifted, window)
  4. Replacing current page with a frame
  5. JS loads (eg, Google Search results when JavaScript is enabled)
  6. Session restore loads
  7. Undo close tab loads

2. Resets search to default:
  1. Chrome (about:) Link loads (eg, new tab page thumbnail click)
  2. External load (eg, from command line when browser is already open)
  3. Chrome loads (other than [1.1] and [1.2]) including location bar and places

Comment 40

[Adam]

Attachment: WIP v4: frontend: Rework search.xml changes to not use indices.

In building some tests for this feature I realized that tabs keeping the engine index wouldn't work if the engines are reordered, removed, added.  Now this uses the engine name, which is unique.

Comment 41

[Adam]

Attachment: WIP v4: backend: split out as separate patch

Comment 42

[Adam]

Attachment: WIP v4: tests: Add tests.

The tests so far are:
1. New tab with persisting search
2. New tab with reset search
3. Changing tabs with different search values for each
4. Page load with reset search

Comment 43

[Adam]

Attachment: tests: Add a meta refresh test

Comment 44

[Adam]

Attachment: backend: Treat meta refresh/similar as browsed to.

Comment 45

[Adam]

Attachment: WIP v5: frontend: Enable getting search data for new window via its opener.

The opener-based searchData code is specifically for sites that use |window.open()| when the user does not have new windows redirected to tabs.  The updated backend patch is to support that by setting the proper flag, only if called from JS.

This also allows for tab drag/drop between windows to carry the search data with the tab, and it makes initial changes toward removing the nsSearchService's currentEngine, as that loses meaning now that multiple windows and tabs have different engines.

The tests will need to be reworked when nsSearchService's currentEngine goes away, along with the observer notification for when currentEngine changes.

Comment 46

[Adam]

Attachment: WIP v5: backend: Set browsed flag for window open calls from JS.

Comment 47

[Adam]

Attachment: WIP v5: tests: Update to work with other current changes.

Comment 48

[Adam]

Attachment: WIP v6: frontend: Rework the window.open() case so it won't recur.

The window.open() case could recur in the previous iteration, so this prevents that by ensuring it only happens if the data hasn't been set yet.

The backend patch removes the notion of a current engine from the search service, and the frontend also updates the observers to not look for the current engine change topic.

The tests are also updated to handle the search service API with the current engine removed.

When adding an engine that's set to be used immediately, only the active window's active tab has the engine changed.

Comment 49

[Adam]

Attachment: WIP v6: backend: Removes current engine from nsSearchService.js and nsIBrowserSearchService.idl

Comment 50

[Adam]

Attachment: WIP v6: tests: Rework search tests now that the "engine-current" topic is gone from search service notifications.

Comment 51

[Adam]

Attachment: WIP v7: backend: Don't remove the global currentEngine.

From reading all the dupes, the selected engine shouldn't be tab-specific.  If that's desirable, the previous work here can be resurrected.

The other stand-out from the dupes was that most people want new tabs to have an empty search bar, so that's now the case.

Comment 52

[Adam]

Attachment: WIP v7: frontend: Don't make engine tab-specific, new tabs get reset search.

Comment 53

[Adam]

Attachment: WIP v7: tests: Don't change other tests, don't change or test for change of engine.

Comment 54

[Adam]

Attachment: WIP v7: frontend: Unbitrot

Comment 55

[Boris Zbarsky [:bzbarsky]]

How is this new flag different from LOAD_LINK exactly?

Comment 56

[Boris Zbarsky [:bzbarsky]]

And in particular, so far this is a pretty automatic "r-, document", but I'd like to understand what problem that flag is actually trying to solve....

Comment 57

[Adam]

My assumption was that LOAD_LINK/LOAD_FLAGS_IS_LINK would be strictly for links and form submissions; the new flag gets used by some JS and chrome loads.

The problem being solved is that each load requires either:

1. persisting the search if it's part of an existing browsing activity
2. resetting the search if it's the start of a new browsing activity

This approach adds the flag to type-1 loads (fewer of that type).  The flag eventually gets translated to a web progress flag that's listened for in the tabbrowser location change listener.

Comment 58

[Chris Lee (:cleer)]

As discussed by the UX team in https://bugzilla.mozilla.org/show_bug.cgi?id=565552 , we'd like the find bar's visibility, search term, and probably toggle options to be specific to each tab rather than global.

Comment 59

[Adam]

(In reply to Chris Lee (:cleer) from comment #58)
> As discussed by the UX team in
> https://bugzilla.mozilla.org/show_bug.cgi?id=565552 , we'd like the find
> bar's visibility, search term, and probably toggle options to be specific to
> each tab rather than global.

The bug for the Find Bar is bug 537013.  I've marked it blocking bug 565552 :)

Re: this bug: Not pursuing this for the time being.  There's awesome work being done on Multi-search [1] (demonstrated in the Product Design at Mozilla presentation [2] as "Search tabs").  That work has a high probability of making this moot.

1. https://wiki.mozilla.org/Features/Desktop/multi-Search
2. https://air.mozilla.org/product-design-at-mozilla/

Comment 60

[Chris Lee (:cleer)]

(In reply to Adam [:hobophobe] from comment #59)
> (In reply to Chris Lee (:cleer) from comment #58)
> > As discussed by the UX team in
> > https://bugzilla.mozilla.org/show_bug.cgi?id=565552 , we'd like the find
> > bar's visibility, search term, and probably toggle options to be specific to
> > each tab rather than global.
> 
> The bug for the Find Bar is bug 537013.  I've marked it blocking bug 565552
> :)
> 
Oops. Wrong bug. Thanks, Adam! :)
> Re: this bug: Not pursuing this for the time being.  There's awesome work
> being done on Multi-search [1] (demonstrated in the Product Design at
> Mozilla presentation [2] as "Search tabs").  That work has a high
> probability of making this moot.
> 
> 1. https://wiki.mozilla.org/Features/Desktop/multi-Search
> 2. https://air.mozilla.org/product-design-at-mozilla/

Comment 61

[Milan Sreckovic [:milan] (needinfo for best results)]

(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #5)
> Well, I definetely like current Firefox's behavior, _not_ clearing search box
> when switching tabs.
> My favorite editor (editpad) also doesn't clear the search box when
> switching tabs.

I also happen to use the "feature" of not clearing the search box a lot.  I will do a search, follow some links in the same tab, rather than opening them in a new one, then want to repeat the search.  It's nice to be able to just open a new tab and have the same search still in there.  Not arguing that I have the most efficient workflow, just that it seems I end up doing it a lot.

Comment 63

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

Comment on attachment 626243 [details] [diff] [review]
WIP v7: tests: Don't change other tests, don't change or test for change of engine.

These have bitrotted. They were left in this state in my queue mostly because answering the "should we do this?" question (as opposed to the "is this done right?" question) is difficult.

We should triage this bug and make that decision, but in the mean time having these patches in my review queue is not useful.

Comment 64

[merfius]

I wholeheartedly disagree.  Whenever you click or Ctrl+K into the searchbar, it selects all the text anyway.  Text remaining there is a non-issue, but strict loss of functionality (loss of the ability to repeat searches) is.

This would cause the same problem as https://bugzilla.mozilla.org/show_bug.cgi?id=537013 but worse.

Comment 65

[macster_smart]

Dude you are a **** retard by requesting this **** and Mozilla developers are even more retarded by implementing this **** now you have just **** up the search functionality of Firefox browser, GO **** YOURSELF FOR REAL and die in pain.

Comment 66

[Boris Zbarsky [:bzbarsky]]

Just to make it clear, comment 65 is NOT an acceptable mode of interaction in this bug database.

Comment 67

[macster_smart]

But you guys are **** stupid how could you agreed on implementing a retarded way of searching through webpages when the old one was the right one and the best way of searching ?

Comment 68

[macster_smart]

Now you can't just type a word in the search box and search it over a dozen of webpages really fast instead you have to bring up the search box every time and type the same word dozen of times if you wanna search it over a dozen of sites like retards do it instead.
Only a **** up retard could have requested this type of tab-specific search.

Comment 69

[Andrei M Eichler]

You are confusing the search in page with search bar/box, right next the url bar

Comment 70

[Andrei M Eichler]

One issue that this bug would solve is cleaning the search bar after a successful search, doesn't make sense the search bar be filled with a query that's was already answered in one tab.

Also, I can tell some embarrassing stories of when someone came to talk to me and look to my browser and there's some NSFW query on search bar.

Comment 71

[macster_smart]

Dude you are a **** retard by requesting this **** of tab-specific search and Mozilla developers are even more retarded ones by implementing this **** now you have just **** up the search functionality of Firefox browser, GO **** YOURSELF FOR REAL and die in pain.

Comment 72

[macster_smart]

(In reply to Andrei M Eichler from comment #69)
> You are confusing the search in page with search bar/box, right next the url
> bar

What the **** are you talking about ? there's no search in page with the search bar next to the url.

Comment 73

[macster_smart]

(In reply to Andrei M Eichler from comment #70)
> One issue that this bug would solve is cleaning the search bar after a
> successful search, doesn't make sense the search bar be filled with a query
> that's was already answered in one tab.
> 
> Also, I can tell some embarrassing stories of when someone came to talk to
> me and look to my browser and there's some NSFW query on search bar.

Are you **** kidding me ? In your **** brain it doesn't make sense that one could search for the same thing in many other webpages ?

Embarrassing stories of you searching for kiddie porn ?

Comment 74

[Matthew Morley]

(In reply to macster_smart from comment #73)

> Are you **** kidding me ? In your **** brain it doesn't make sense that one
> could search for the same thing in many other webpages ?

The search bar does not search within a web page. The search bar is for searching in Google, Yahoo etc (whatever preset you have).

As mentioned previously, you appear to be confusing this with the 'Find' bar that you bring up with CMD+F / CTRL+F. That is the one that searches for matching text within a webpage. The contents of this one DOES persist across tabs.

Can I also suggest that you be a bit more polite? No one is having a go at you but you seem to be very aggressive in your writing style.

Comment 75

[Boris Zbarsky [:bzbarsky]]

[e-mail], I've disabled your account due to the abusive comments you're posting after being warned not to do so.  I've tagged said comments as "spam".  I have _not_ thus tagged your comments that contain something useful other than invective.  Please feel free to contact me to reenable your account when you feel you've calmed down enough to engage in a discussion productively.

Past that, Andrei is right: you're commenting in the wrong bug.  This bug is about the search box for doing web searches, which is located to the right of the URL bar in the default configuration.  What you're talking about the "find in page" search box, which is not what this bug is about.

Had you actually looked at this bug enough to notice that it's not actually resolved, instead of jumping straight to name-calling, you might have realized that it can't possibly be the cause of the behavior change in the "find in page" search box that you're seeing, because there haven't been any changes actually made in this bug yet.

Comment 76

[awb95]

Guys are we using the same browser or different ones ? Since "Find in page" search box acts exactly how this retard has asked for, as I explained now you can't just type a word in the "Find in page" search box and search it over a dozen of webpages really fast instead you have to bring up the "Find in page" search box every time and type the same word dozen of times if you wanna search it over a dozen of sites.
Who **** up the "Find in page" search box functionality then may I ask ?

Comment 77

[Boris Zbarsky [:bzbarsky]]

> Guys are we using the same browser or different ones ?

Same one.

> Since "Find in page" search box acts exactly how this [elided]

Please watch your language.  Otherwise I will disable this account as well.  This sort of thing is NOT acceptable.  

And again, you're addressing your invective to the wrong person.

> now you can't just type a word in the "Find in page" search box and search it over a
> dozen of webpages really fast

Yes, this was apparently a deliberate change to the "Find in page" search box behavior.  I'm not too fond of that change myself, but the people who made it had good reasons for it, unfortunately.

https://addons.mozilla.org/en-US/firefox/addon/findbar-tweak/ may let you produce a behavior more to your liking (or not; I haven't actually tried it myself).

> Who **** up the "Find in page" search box functionality then may I ask ?

Frankly, I would be more likely to tell you if I thought you'd then go and read the relevant bug to find out why they did it.  Since I'm pretty sure what you'll do instead is go curse at them, I don't think enabling that would be a good idea.

Comment 79

[awb95]

As is it stated that FindBar Tweak addon will make your find toolbar "just right" because now is totally **** up.

Comment 81

[Greg]

I vote against this. Search-box should NOT be tab specific.

If you open a new tab and then tap CTRL+K and start typing, it writes over what was there. What is the problem with this? Why do you need the search field blank? The behavior you guys are proposing has resulted in a miserable experience for people since it was instituted in Firefox's "Find in page" feature. And now you want the search-box to have this awful behavior too?

Since this behavior was adopted by "Find in Page" it has be a horrible experience. Say I have five tabs open. I want to find out if specific text appears anywhere in the five tabs. So in Tab-1 I tap CTRL+F and type out what I want found: nothing is found in the search of Tab-1. I move to Tab-2 and tap F3 but there is no text in the Find box. I tap CTRL+F but it is blank. I HAVE TO RETYPE WHAT I WANT FOUND FOR EVERY SINGLE TAB I SEARCH IN. This is frustrating and a PITA to deal with. I really wish Firefox would revert back to the old "Find in page" behavior and remember Find-requests across tabs. But now you guys want to add this miserable behavior to the search-bar too? What is so hard about tapping CTRL+K and then typing? CTRL+T opens a new tab, CTRL+K positions to the search-bar and highlights anything there, type out your search. Why does the field need to be empty?

(In reply to Aaron Sloman from comment #1)
> I strongly support this proposal. I frequently start a new tab in firefox
> because I wish to do a new search (usually in google). The new tab always
> comes
> up with a clear box for a url, which is sensible, but it does not start with
> a
> clear search box. I don't understand the reason for this inconsistency.
> 
> I wonder if it is worth doing any kind of survey to find out how many people
> actually welcome saving the previous search box contents when they start a
> new tab.
> 
> Aaron
> ===
> www.cs.bham.ac.uk/~axs

Comment 82

[Greg]

apparently there is no way to edit a comment. One reason for "the inconsistency" as you put it is that after you do a search in a tab and find something of interest, you may want to leave that tab open and perform a similar search in a new tab. So you tap CTRL+T and make a slight modification to the search terms in the search-box. If the search-box is made empty in the new tab you have to retype your entire search query out again. 

(In reply to Greg from comment #81)
> I vote against this. Search-box should NOT be tab specific.
> 
> If you open a new tab and then tap CTRL+K and start typing, it writes over
> what was there. What is the problem with this? Why do you need the search
> field blank? The behavior you guys are proposing has resulted in a miserable
> experience for people since it was instituted in Firefox's "Find in page"
> feature. And now you want the search-box to have this awful behavior too?
> 
> Since this behavior was adopted by "Find in Page" it has be a horrible
> experience. Say I have five tabs open. I want to find out if specific text
> appears anywhere in the five tabs. So in Tab-1 I tap CTRL+F and type out
> what I want found: nothing is found in the search of Tab-1. I move to Tab-2
> and tap F3 but there is no text in the Find box. I tap CTRL+F but it is
> blank. I HAVE TO RETYPE WHAT I WANT FOUND FOR EVERY SINGLE TAB I SEARCH IN.
> This is frustrating and a PITA to deal with. I really wish Firefox would
> revert back to the old "Find in page" behavior and remember Find-requests
> across tabs. But now you guys want to add this miserable behavior to the
> search-bar too? What is so hard about tapping CTRL+K and then typing? CTRL+T
> opens a new tab, CTRL+K positions to the search-bar and highlights anything
> there, type out your search. Why does the field need to be empty?
> 
> (In reply to Aaron Sloman from comment #1)
> > I strongly support this proposal. I frequently start a new tab in firefox
> > because I wish to do a new search (usually in google). The new tab always
> > comes
> > up with a clear box for a url, which is sensible, but it does not start with
> > a
> > clear search box. I don't understand the reason for this inconsistency.
> > 
> > I wonder if it is worth doing any kind of survey to find out how many people
> > actually welcome saving the previous search box contents when they start a
> > new tab.
> > 
> > Aaron
> > ===
> > www.cs.bham.ac.uk/~axs

Comment 83

[Greg]

Another reason to keep the "old search query" in the search box in a new tab is if you want to perform the same search with a different search engine.

An example: I perform a search in Tab-1 with search-engine-1. I select from the search results and bring up a webpage. Now I want to perform the same search with search-engine-2 but keep Tab-1's webpage open. So I open a new tab and via the search-box's drop-down select search-engine-2. Since the text from the old search is still present in the search-box I do NOT have to retype my old search. I can just tap Enter.

If the search-box clears with each new tab, I am left having to RETYPE my search queries constantly, recreating the same miserable experience Firefox currently provides when using the Find-In-Page search box.

Comment 84

[Kuba Niewiarowski]

Nope nope nope nope. Don't destroy well-loved search bar usage scenario as handy quicknote area. There is no easiest and greatest solution. :x

Comment 85

[Antoine Turmel [:GeekShadow]]

With Firefox 57 it's impossible to bring back global search with an add-on :(
I use to like to be able to search for a word in multiple tabs !