Firefox search box should be tab specific

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

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

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

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.

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

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.

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

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

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

(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

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

(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

(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

Opera also supports tab-specific search bar contents.

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

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

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

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

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.

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

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

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

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

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

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

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

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

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.

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

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.

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.

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.

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

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.

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

Created attachment 603512
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).

Created attachment 605120
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.

Created attachment 620559
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

Created attachment 620906
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.

Created attachment 620907
WIP v4: backend: split out as separate patch

Created attachment 620909
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

Created attachment 622897
tests: Add a meta refresh test

Created attachment 622898
backend: Treat meta refresh/similar as browsed to.

Created attachment 624244
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.

Created attachment 624245
WIP v5: backend: Set browsed flag for window open calls from JS.

Created attachment 624246
WIP v5: tests: Update to work with other current changes.

Created attachment 625243
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.

Created attachment 625247
WIP v6: backend: Removes current engine from nsSearchService.js and nsIBrowserSearchService.idl

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

Created attachment 626240
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.

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

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

Created attachment 630282
WIP v7: frontend: Unbitrot

How is this new flag different from LOAD_LINK exactly?

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

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.

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.

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

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

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

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

Comment on attachment 626243
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.

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.

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

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

But you guys are fucking 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 ?

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 fucked up retard could have requested this type of tab-specific search.

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

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.

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

(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 fuck are you talking about ? there's no search in page with the search bar next to the url.

(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 fucking kidding me ? In your fucked 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 ?

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

<email address hidden>, 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.

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 fucked up the "Find in page" search box functionality then may I ask ?

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

a deliberate change ? people who made it had good reasons for it ? are you kidding me that sure was one stupid idea made by some idiots.

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

(In reply to Boris Zbarsky [:bz] from comment #77)
> Please watch your language. Otherwise I will disable this account as well.
> This sort of thing is NOT acceptable.
An you should re-enable my old account otherwise I will not report any more bugs in that way your browser will become more buggy and less user friendly, if the issues I reported won't be fixed only retards will use a retarded browser.

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

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

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.

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

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 !

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