Search bar for filtering tabs
The tab bar (especially when vertical) should have a find-as-you-type search box letting you filter the tab bar by title and url (and optionally page text) to help you find tabs faster. See mockup of the tab bar after filtering by "goog": http://tinyurl.com/tk-mockup-searchresults
Thank you for adding this brilliant feature, there are times I couldn't do without it. I don't think I'd ever need the search bar to be hidden, but I appreciate others might.
Thanks for the link provided by IByte
Customizability is very important in this era
A forced feature would violent it
So please just add an option for turning it off, it won't take much time right?
This feature is proving to be rather unpopular with unsuspecting updaters. Take a look at the issue tracker; it became the top rated issue in under two days: http://code.google.com/p/tabkit/issues/detail?id=113
I think Chris has a point here, from a software development point of view, adding such a forced feature might not have been such a great idea.
I rarely have that many open tabs that would give this intrusively visible feature any added value. Could you please make this thing configurable, i.e. give us the option to make it disappear entirely? I think the rest of Tab Kit is quite useful, by the way.
Chris Fallowfield commented
I'm gonna have to side with Phil on this, while it certainly is a potentially useful addition, adding a new feature without adding the relevant checkbox in the options panel to allow users who don't want it to turn it off, is pretty much a prime example of a bad developing practice.
Also, while admittedly, I'm just nitpicking now, when used with the aquatint theme, the top of the search box overlaps the bottom of the first entries on my bookmarks tool-bar, by about 4px.
Philip Goddard commented
Well, now we have the search bar. It's a great idea, but what I need is a means to *turn it off*, because I myself rarely have need for it, and therefore normally it's just a bit of clutter that I want to clear from the tab bar.
Wayne Mery commented
tabhunter does an amazing, amazing job - so I for one wouldn't be displeased if tabkit didn't get this feature.
(however, tabhunter doesn't show the tabs in context of other tabs, etc.)
eat more meat commented
This feature request ought be rolled into a new, separate extension AND NOT included in lightweight TabKit!!
I b'lieve this is coming to the location bar (type a character to limit filtering to currently-open tabs, then go to the one selected), eventually.
The "Tabhunter" addon (https://addons.mozilla.org/en-US/firefox/addon/7924 ) currently does something similar.
Neither is exactly what was requested, I guess, but maybe there's some useful ideas in there.
For me, just what was shown at http://tinyurl.com/tk-mockup-searchresults is the most important thing. Even with the vertical tab layout, grouping, and coloring, I spend too much time hunting visually for tabs. But I can usually remember some text from the page title or URL, so filtering tabs based on that would be a big timesaver. (This is like compiz's Scale Window Title Filter for finding the window you want -- here, I'm already in the right window (Firefox) but I need to dive down to find the right tab.)
There seems to be such an extension already for Chrome:
While the keyboard focus is still on the search box, I would like to be able to use the keyboard to select one of the results from the filtered list, rather than switching to the mouse. Perhaps while the focus is on the search box, the vertical arrow keys could move among the tabs shown in the current filtered list. This is probably what narayan means by "User can quickly cycle through these tabs." As he or she says, since each tabbed page would presumably be shown as the user cycled to it, the tabbed page could highlight matches within the full text.
I would rather not have a separate keystroke '/' for fulltext search. If you want to add fulltext search, just keep it simple for the user and have one search UI, just as the AwesomeBar does. The tabs whose titles or URLs match should be listed first, and fastest, at the top. Then additional tabs that have a fulltext match can be added below that (at least if the number of matches at the top is small). Bear in mind that the user may be typing new characters into the search box faster than the matching can be done.
Scrolling is an interesting issue. I suggest that when the user cycles to a tab using the vertical arrow keys, we highlight all matches in the tab name and on the tabbed page full text. If the only matches are in the full text, and none of them are currently visible in the window, then scroll until at least one is visible. But if the user leaves this tab while search mode is still active (cycles to or clicks on a different tab while the keyboard focus is still on the search box), then restore the original scrolling position of the tab we just left.
When the user leaves search mode by pressing Esc or Enter or clicking on a tab, I am not sure what the right behavior is for scrolling or highlighting matches in the now-current tab. One option is to handle it exactly as if the user had cycled to the current tab -- i.e., if the search string is not in the tab title or URL, then scroll if needed to ensure that at least one match is visible in the window. Perhaps ensure that this match is highlighted by automatically starting up an ordinary Firefox Ctrl-F search with the same search string.
For those (like me) who use top-mounted tabs, adding this to the tab list would be a GoodThing™, as I really don't need another tab to search my tabs, but if I need a tab that's in a collapsed group, this would be handy.
Yes, hiding tabs would be fantastic.
When the user presses ESC, the search is over. Then all the rest of the tabs can pop up (in their original positions) again.
AdminJomel (Admin, Tab Kit) commented
Ah that makes sense. Short-listing tabs was always the plan (non-matching tabs would be hidden completely while searching). Highlighting could be a nice bonus though probably not a priority.
The latter: A plain "/" searches the full text in only the current tab. A modifier should work in all tabs in exactly the same way (i.e., search full text; not just the titles). Further, short-listing tabs that have the string AND also highlighting all occurrences would make the task very simple.
Generally I use the tabs to research a topic. I use the "/" to look for a particular keyword that may not exist in all those pages, although all are on the same topic. I have to switch tabs and try F3 in each to see if it contains the string. Often it does not. This trial-and-error method can be avoided altogether.
I think this would be a common scenario for power users.
AdminJomel (Admin, Tab Kit) commented
@narayan: By "Modify the search (when user presses /)" do you mean that the default Firefox find-as-you-type search should be changed to search all tabs? I'd rather not change that, as it works well already, and I think users will generally know in advance whether they want to search all tabs or just the current tab. Or do you mean that "/" should be the modifier that tells Tab Kit's (future) search bar to search full text instead of just titles and addresses?
Modify the search (when user presses /) like this:
* The string is searched in all tabs.
* Tabs that have the string are highlighted.
* User can quickly cycle through these tabs (leaving other tabs)
* In each matching tab, all matching instances are highlighted using a color that is complementary to the background color