Open Bug 565740 Opened 14 years ago Updated 2 years ago

Clear the chrome search field input when navigated away from the results page, and make it tab-specific

Categories

(Firefox :: General, defect, P5)

defect

Tracking

()

Tracking Status
blocking2.0 --- -

People

(Reporter: jhill, Unassigned)

References

(Depends on 2 open bugs, Blocks 1 open bug)

Details

(Keywords: polish, privacy, Whiteboard: [target-betaN] [Advo][fxsearch])

(Note: this is filed as part of the “Paper Cut” bugs — we assume that there may be multiple existing bugs on this. Please make them block this bug, and we will de-dupe if they are indeed exactly the same. Thanks!)

To reproduce:
1. perform a search using the chrome search bar
2. navigate away from the results page
3. notice how the search terms you entered are still in the chrome search (even on multiple tabs)

Recommendation:
Clear the chrome search when a user navigates away from the results page.
Also, make the chrome search tab specific so that my search terms don't appear on multiple tabs at once
Depends on: 253331
Now that we've landed tabs-on-top, this is the only remaining major inconsistency in the visual UI hierarchy / conceptual model of the default browser window. (See Faaborg's awesome tabs-on-top video.)
Requesting blocking to pick up wanted+.
blocking2.0: --- → ?
As filed, I think this is wontfix/not doable.  Consider those cases:

1. Going to the next results page
2. Going back to a result page.
3. Switching the search term within the results page
4. Search engines that don't go to result pages.

However, we could fix the issue raised in comment 1 by creating a per-tab search term.
Indeed, a strong heuristic must be presented/proposed to make this work.

I think that the following will suffice:

 - search terms should be per-tab (as proposed in comment 3)
 - search terms should be cleared when the user does one of the following
     - types in a new URL
     - loads a new URL by dragging one onto the tab
     - loads a new URL from a bookmark
     - (basically, anything other than following a link)
Not a blocker, definitely wanted, anyone disagree with my idea/heuristic in comment 4?

Needs an owner.
blocking2.0: ? → -
Keywords: polish, privacy
Assignee: nobody → mano
Nice, we have an owner!
Depends on: 248955
Whiteboard: [target-betaN]
Alex points out that we probably want to land this at the same time as (or before) bug 592909 because that bug will make it so the user can't tell which search service is selected if text is entered in the search field.
Blocks: 592909
Mano, have you been working on this? The UX team has identified this as a priority, and I don't mind taking it if you've been too busy with other things to work on it.
Would it be too late to ask *not* to implement this? This feature is one of the main reasons why I use the search bar instead of setting keywords in the location bar.

This is for one simple reason: multiple engine search. This often happens when I look up a song on Youtube, for example. I type in the name of the song, and while listening, I quickly open a new tab and search for the lyrics on Google - with the same search terms.

Another use case would be when I look up some information, which I often do on Wikipedia first, instead of on Google or another search engine. Sadly, I don't find the information that I want, buy curious as I am, I saw an interesting looking link to another Wikipedia article, which I click. When I want to look up more about the subject I actually needed information about, I just ctrl-k to the search bar again, and look for the same keyword on Google.

Those are only two cases where I happen to use this feature a lot. I'm sure there are more. So while there are obvious advantages to keeping the text there, the only disadvantage mentioned is the "visual inconsistency of a tabbed interface". Visual inconsistencies might be annoying, but not as annoying as missing features you're used to. A user interface should *never* give up user friendliness for beauty. And I even think that the win there is very minimal.

(If this already has been discussed or if I should take it somewhere else, please tell me. I know Bugzilla isn't meant for yes/no debates, but I just don't know where I should post it anywhere else)
(In reply to Tim from comment #10)
> Would it be too late to ask *not* to implement this? This feature is one of
> the main reasons why I use the search bar instead of setting keywords in the
> location bar.

If a bug is still at "NEW", I'd say it's never too late to discuss it further. ;)

That being said, I disagree with your request, for reasons I will address below. :)

> This is for one simple reason: multiple engine search. This often happens
> when I look up a song on Youtube, for example. I type in the name of the
> song, and while listening, I quickly open a new tab and search for the
> lyrics on Google - with the same search terms.

Interesting... but, as someone who uses a keyword to search YouTube directly, my workflow would likely be like this: open a new tab, type 'yt XYZ Song' in the location bar, play the song, open another new tab, type 'XYZ Song lyrics' in the location bar and let the (customized) default search take it away.

Admittedly, this does require some duplication of work—but I don't often have to look up lyrics to the songs I'm listening to on YouTube (either because they're already in the description, or because I already know them).

> Another use case would be when I look up some information, which I often do
> on Wikipedia first, instead of on Google or another search engine. Sadly, I
> don't find the information that I want, buy curious as I am, I saw an
> interesting looking link to another Wikipedia article, which I click. When I
> want to look up more about the subject I actually needed information about,
> I just ctrl-k to the search bar again, and look for the same keyword on
> Google.

Again, my POV is somewhat different. I always have Wikipedia as an App Tab, so it's never really assigned to a specific search term—it's just there for whatever I need it for.

If it turns out that Wikipedia is insufficient for what I was looking for, I would open a new tab, type the search terms again (probably in a modified form, since there are different strategies for searching Wikipedia and searching Google), and let the default search take it away.

> Those are only two cases where I happen to use this feature a lot. I'm sure
> there are more. So while there are obvious advantages to keeping the text
> there, the only disadvantage mentioned is the "visual inconsistency of a
> tabbed interface". Visual inconsistencies might be annoying, but not as
> annoying as missing features you're used to. A user interface should *never*
> give up user friendliness for beauty. And I even think that the win there is
> very minimal.

Admittedly, my versions of your use cases appear to duplicate some work, in terms of having to retype the search terms. But part of that may be that I think of YouTube and Wikipedia in a different way than I think of Google (whether it be in the dedicated Search bar or the default search in the Location bar).

Thus, I also present to you an objective reason for making the Search bar be tab-specific: privacy. (And distraction/confusion, if I may add more reasons.) When you search something in the current Search bar, those search terms remain there for the remainder of the time the browser is open, no matter how many new tabs you've opened or how many you've closed or how long it's been since you made that search, unless you decide to manually clear it or search for something else. By switching the Search bar to be tab-specific, those search terms disappear whenever you close their related tab or open a new tab. Thus, you are saved from the distraction and privacy issues of having your really old search terms persist when you're doing something else.

But as yours, these are only my two cents. Having just now re-read the previous comments, I would like to make the case that there is no need to have the Search be aware of what pages you've visited since you searched, nor whether or not you're still on the results page. I think merely making the search box be tab-specific would be sufficient.

(I should note for the record that I turn off the saving of search and form field data, a setting which could influence how you and your brain use the Search bar. I should also note that this preference has no effect on whether the most recent search term persists in the Search bar.)
(In reply to Gordon P. Hemsley [:gphemsley] from comment #11)
> > This is for one simple reason: multiple engine search. This often happens
> > when I look up a song on Youtube, for example. I type in the name of the
> > song, and while listening, I quickly open a new tab and search for the
> > lyrics on Google - with the same search terms.
> 
> Interesting... but, as someone who uses a keyword to search YouTube
> directly, my workflow would likely be like this: open a new tab, type 'yt
> XYZ Song' in the location bar, play the song, open another new tab, type
> 'XYZ Song lyrics' in the location bar and let the (customized) default
> search take it away.
> 
> Admittedly, this does require some duplication of work—but I don't often
> have to look up lyrics to the songs I'm listening to on YouTube (either
> because they're already in the description, or because I already know them).

Well, do you know the song "You probably couldn't see for the lights but you were staring straight at me" from Arctic Monkeys? :P
I think you're getting my point about duplicating searches. It's okay only for short and search terms. I wouldn't like retyping my laptop model number too often.

> > Another use case would be when I look up some information, which I often do
> > on Wikipedia first, instead of on Google or another search engine. Sadly, I
> > don't find the information that I want, buy curious as I am, I saw an
> > interesting looking link to another Wikipedia article, which I click. When I
> > want to look up more about the subject I actually needed information about,
> > I just ctrl-k to the search bar again, and look for the same keyword on
> > Google.
> 
> Again, my POV is somewhat different. I always have Wikipedia as an App Tab,
> so it's never really assigned to a specific search term—it's just there for
> whatever I need it for.
> 
> If it turns out that Wikipedia is insufficient for what I was looking for, I
> would open a new tab, type the search terms again (probably in a modified
> form, since there are different strategies for searching Wikipedia and
> searching Google), and let the default search take it away.

Well, you can't expect everybody to have a Wikipedia app tab, can you? Saying it isn't a problem for you, doesn't mean it isn't for anyone else.

Also, now I think about it, two more use cases:
- Changing search term inside the search box is faster than going back in history till you get back to the Google page and changing the terms there. Also, I don't need my mouse for it.
- Situation: I searched for something and got an interesting result. But I saw another interesting result too or I just want to look at some other pages first to compare the results, so I quickly open a new tab, ctrl-k enter and voilà, I'm back on Google.

> Thus, I also present to you an objective reason for making the Search bar be
> tab-specific: privacy. (And distraction/confusion, if I may add more
> reasons.) When you search something in the current Search bar, those search
> terms remain there for the remainder of the time the browser is open, no
> matter how many new tabs you've opened or how many you've closed or how long
> it's been since you made that search, unless you decide to manually clear it
> or search for something else. By switching the Search bar to be
> tab-specific, those search terms disappear whenever you close their related
> tab or open a new tab. Thus, you are saved from the distraction and privacy
> issues of having your really old search terms persist when you're doing
> something else.

Well, people who care that much about their privacy, probably clear their search history anyway, when they don't need it anymore. At least I do when I'm done searching. But I do understand your point.
On the other hand, with a tab specific search bar, you might switch tabs and suddenly see an unwanted search term appear... If it's global, at least you're sure it's gone everywhere, when you've deleted it.

> But as yours, these are only my two cents. Having just now re-read the
> previous comments, I would like to make the case that there is no need to
> have the Search be aware of what pages you've visited since you searched,
> nor whether or not you're still on the results page. I think merely making
> the search box be tab-specific would be sufficient.

A hybrid solution which would take into account the four scenarios I've mentioned, would be indeed "Per-tab history", but with one added feature: when creating a new tab, copy the search box value of the current active tab. Would that be sufficient?

Or otherwise, this feature could be implemented with an about:config entry to put it back off. The default can be to clear the box. As long as I can change it back, you can do whatever you want, really. That's the exact reason why I like Firefox so much :)
(In reply to Tim from comment #12)
> (In reply to Gordon P. Hemsley [:gphemsley] from comment #11)
> Well, you can't expect everybody to have a Wikipedia app tab, can you?
> Saying it isn't a problem for you, doesn't mean it isn't for anyone else.

That was actually my point, as well. We both have perfectly valid workflows that just so happen to be mutually exclusive. :)

> Also, now I think about it, two more use cases:
> - Changing search term inside the search box is faster than going back in
> history till you get back to the Google page and changing the terms there.
> Also, I don't need my mouse for it.
> - Situation: I searched for something and got an interesting result. But I
> saw another interesting result too or I just want to look at some other
> pages first to compare the results, so I quickly open a new tab, ctrl-k
> enter and voilà, I'm back on Google.

In that situation, I tend to use the "Open link in new tab" option on the context menu, which leaves the original results page untouched.

> Well, people who care that much about their privacy, probably clear their
> search history anyway, when they don't need it anymore. At least I do when
> I'm done searching. But I do understand your point.

I'm not sure I agree with that. But perhaps it's just because I prefer to have the search box empty if I decide to do a new search.

> On the other hand, with a tab specific search bar, you might switch tabs and
> suddenly see an unwanted search term appear... If it's global, at least
> you're sure it's gone everywhere, when you've deleted it.

Well, if you're switching back to an existing tab, I would that the search terms in the box would at least be somewhat related. I can't speak to how "wanted" they might be, though.

> > But as yours, these are only my two cents. Having just now re-read the
> > previous comments, I would like to make the case that there is no need to
> > have the Search be aware of what pages you've visited since you searched,
> > nor whether or not you're still on the results page. I think merely making
> > the search box be tab-specific would be sufficient.
> 
> A hybrid solution which would take into account the four scenarios I've
> mentioned, would be indeed "Per-tab history", but with one added feature:
> when creating a new tab, copy the search box value of the current active
> tab. Would that be sufficient?

Actually, for me, the new tab page would be the most important place where the Search box should be empty. ;)

> Or otherwise, this feature could be implemented with an about:config entry
> to put it back off. The default can be to clear the box. As long as I can
> change it back, you can do whatever you want, really. That's the exact
> reason why I like Firefox so much :)

Any situation where we can both get our way is fine by me. :)
The solution described in comment 4 is in my opinion the way to go.

It would solve use cases described in comment 10 & comment 12. Search, click result, focus search bar and hit alt + enter to search again in new tab, with or without modifying the query/search engine.
What about opening a new tab? Most users don't use keyboard shortcuts - and tbh, even I didn't know about that one. I'm not sure if it's intuitive, actually. When following a link, you need to hold ctrl to open a new tab instead of alt. But thanks for the useful information.

Personally, I would still like to keep the current behaviour, so please make it configurable :)
(In reply to Tim from comment #15)
> What about opening a new tab? Most users don't use keyboard shortcuts - and
> tbh, even I didn't know about that one. I'm not sure if it's intuitive,
> actually. When following a link, you need to hold ctrl to open a new tab
> instead of alt. But thanks for the useful information.

Yeah, ctrl is indeed more intuitive. I would prefer that but I think it's for consistency with the behaviour of the location bar, where ctrl was taken for ".com" (or whatever) autocompletion. Hold alt to open in new tab in the location bar as well.

Don't know about mouse only users...
I would like to request that, if this really gets implemented, there is a setting to reactivate the old/current behaviour of a global search term.
Whiteboard: [target-betaN] → [target-betaN] [Advo]
Priority: -- → P5
Whiteboard: [target-betaN] [Advo] → [target-betaN] [Advo][fxsearch]
Rank: 59
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
Assignee: asaf → nobody
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 27 votes.
:mossop, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dtownsend)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(dtownsend)
You need to log in before you can comment on or make changes to this bug.