Closed Bug 408078 Opened 17 years ago Closed 28 days ago

Associate search field contents with individual tabs rather than a global search (like Safari)

Categories

(Camino Graveyard :: Toolbars & Menus, enhancement)

All
macOS
enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: bugzilla-graveyard, Unassigned)

Details

(Whiteboard: p-safari)

From a feedback correspondent who didn't feel comfortable enough with Bugzilla to file it herself:

In Safari, when you get a new tab, you get a new search.

Meaning in practice, that you might have half a dozen tabs open and a *separate search field* for *each* tab. In effect, the same number of search results are possible - 6 open tabs, 6 separate sets of search results.

The practical result is that no matter how many tabs are open in Camino now, there is only one search. Say I wanted to search another topic altogether (and since I'm making this request, it's something I often do!) I have to scrub the current search results and start again. That means I can only access the current search results by choosing it in the history and losing sight of whatever I'm searching for now.
Whiteboard: p-safari
Doesn't cmd-return in the search field accomplish this (the not-scrubbing of results)?
I talked more with Elaine through e-mail and she said that using Command-return pretty much solves her problem (at least as much as she cares about), but the larger issue of Safari parity is still there. The Location bar's contents are unique to each tab; is there a compelling reason (other than "it's more work") the search bar's contents should be global?
The only reason that comes to mind is if I'm using "Search this Site" across multiple sites and want to use the same search term.
Summary: Associate search bar contents with individual tabs rather than a global search (like Safari) → Associate search field contents with individual tabs rather than a global search (like Safari)
In the process of investigating bug 395423 tonight, I realised something and did some further investigating...

In Safari 3.1:
• The Location bar is unique to each tab, whether focused or not.
• Switching tabs, which can only be accomplished with the mouse if focus is in the Location bar, removes focus from the Location bar.
• The Search bar is unique to each tab when not focused.
• The Search bar is global when focused.
• Switching tabs, which can only be accomplished with the mouse if focus is in the Search bar, does NOT remove focus from the Search bar.

In Firefox 2:
• The Location bar is unique to each tab, whether focused or not.
• Switching tabs, which is possible via either the keyboard or mouse, removes focus from the Location bar. HOWEVER, if you switch back to the original tab, focus is restored to its Location bar!
• The Search bar behaves exactly like the Location bar.

Currently in Camino trunk nightlies:
• The Location bar is unique to each tab when not focused.
• The Location bar is global when focused.
• Switching tabs with the keyboard or mouse leaves focus in the Location bar.
• The Search bar is global whether focused or not.
• Switching tabs with the keyboard or mouse *removes* focus from the Search bar.

Smokey and I talked about this on IRC tonight. We both find our current Location bar behaviour acceptable (and, in fact, desirable for a number of reasons) but we both agree that, for consistency's sake, our Search bar should behave the same way the Location bar does. That is, Search should be global when focused and unique when blurred, and switching tabs should not remove the focus from the search bar. (And, of course, we'd retain the extremely useful ability to switch tabs with the keyboard no matter where focus is.)
Under the proposed behavior on comment 4, Sam could still do comment 3 if he focused the search field before switching tabs.
Since there seems to be agreement here, confirming.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
The Firefox equivalent of this RFE is bug 544039.
Status: NEW → RESOLVED
Closed: 28 days ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.