similarly to how we can restrict results to just bookmarks, tags, etc, we should allow searches of only the currently open tab set, move to the tab of the selected result.

wip patch that uses annotations to mark URIs as open-in-a-tab, managed by a bit of glue code in /browser. currently uses a tilde as the special character for exclusively searching in tabs. this basically just implements the annotating and the exclusive tab search bits, but still needs: - styling of results to indicate it's a tab - support for recognizing tabs in non-tab-exclusive searches - support for actually switching to the pre-existing tab - not handling location changes in tabs correctly

so every time a user opens a tab you add an anno, and every time a user closes a tab you remove the anno... would not that add a similar problem we have with adding visits and firing an fsyncs? we would fsync at every tab open/restore/close

what about a temp table and look if the result exists in it? the table could be (place_id, tab_index) (if we need to know where is the tab open to go to it) with an index on place_id

What if there are multiple windows? Multiple tabs (in multiple windows) that have the same url? I suppose potentially the same url could have different titles. Should this be something done at the browser level instead of the backend? urlbindings could potentially 1) find results and 2) specially process "gototab" types (vs bookmark, tag, keyword.. the thing that adjusts what icon is shown on the right)

Handling duplicate URLs: suggest to list "closest" duplicate first: - is in same window - is least number of tabs away from currently selected tab - if equidistant, use the one to the left?

(In reply to comment #2) > so every time a user opens a tab you add an anno, and every time a user closes > a tab you remove the anno... would not that add a similar problem we have with > adding visits and firing an fsyncs? we would fsync at every tab > open/restore/close agreed, annotations are not optimal due to this, as well as being high-maintenance, and leaking front-end UI concerns into backend toolkit code. (In reply to comment #4) > What if there are multiple windows? Multiple tabs (in multiple windows) that > have the same url? I suppose potentially the same url could have different > titles. > > Should this be something done at the browser level instead of the backend? yes, front-end filtering would be much better than trying to hack this into the backend. we'll need to be able to optionally hide non-matching results, as well as style matching results. > urlbindings could potentially 1) find results and 2) specially process > "gototab" types (vs bookmark, tag, keyword.. the thing that adjusts what icon > is shown on the right) which bindings are you referring to?

http://hg.mozilla.org/mozilla-central/file/tip/browser/base/content/urlbarBindings.xml There's currently quite a bit of stuff in the base autocomplete.xml toolkit widget, but arguably it should be in urlbarBindings. And here, we could separately search for results (not using places).

I talked to beltzner on IRC earlier about this feature, and it sounds like it's supposed to be more of a "suggest switching to existing tab" more than a "search through open tabs". Meaning, for every regular search result, check to see if that url is already open in some tab and suggest another entry above it to switch to that tab. So typing "m" in the location bar won't show all tabs that have the letter "m" in the title or url. The list will show pages in frecency order as usual, but additionally have an entry that lets the user switch to the tab. This avoids the problem of "m" matching pretty much everything and hiding more useful results. In terms of switching to open tabs, I think we can do something similar as the keyword changes for bug 445955. The changes there makes a keyword search entry's URL be what the user is typing in. E.g., "bug 455650" shows up as title: "Bugzilla search: 455650" url: "bug 455650". The trick here is that urlbarBindings.xml's handleCommand() is what actually handles the entry, so it'll correctly trigger the keyword (and use any POST data if necessary). So for switching tabs, we could make autocomplete entries with fake urls such as.. title: "Switch to Bug 455650 - search open tabs in the awesomebar" url: "switch-to: http://.... 5" Where handleCommand() looks for the special switch-to: "url" and takes the "5" as the tab to switch to. The url junk in the middle is ignored, but is mainly for the user as it shows up on the second line of the autocomplete result. Alternatively, this fake switch-to: "protocol" could be smarter and be "switch-to:<search input>" and handleCommand() will look through the open tabs to find the matching tab.

So again, this feature isn't really a "search through open tabs", so either morph this bug or create a new one? (But.. IIRC, Dao had something for ctrl-tab to search through open tabs..??)

morphing to only cover restricting to open tabs, since bug 480350 covers the identification and selection parts.

(In reply to comment #8) > So for switching tabs, we could make autocomplete entries with fake urls such > as.. title: "Switch to Bug 455650 - search open tabs in the awesomebar" url: > "switch-to: http://.... 5" > > Where handleCommand() looks for the special switch-to: "url" and takes the "5" > as the tab to switch to. The url junk in the middle is ignored, but is mainly > for the user as it shows up on the second line of the autocomplete result. > Alternatively, this fake switch-to: "protocol" could be smarter and be > "switch-to:<search input>" and handleCommand() will look through the open tabs > to find the matching tab. This is the approach I'm taking in bug 480350.

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv

I'm wondering if this bug should be WONTFIX. If someone has so many tabs open that they need to search for them, then that person is probably a very advanced and unusual user. The ability to switch to an open tab from the awsomebar's drop-down list will add to the UI, and thus be a burden on a huge number of users who will never need nor want this feature. BTW: Wouldn't it be better to put a search box in the "List all tabs" drop-down? Perhaps only show the search box when there are more than x open tabs (x = ~10).

(In reply to comment #14) > BTW: Wouldn't it be better to put a search box in the "List all tabs" > drop-down? browser.allTabs.previews

Nice. But the pop-up "window" extends beyond the browser window. It should stay within it.

(In reply to comment #16) > Nice. But the pop-up "window" extends beyond the browser window. It should stay > within it. There's bug 464205 on that.

(In reply to comment #14) > I'm wondering if this bug should be WONTFIX. This is actually part of bug 480350, which is about to land. See that bug for background on the work done on this feature.

to me this bug looks like fixed with bug 480350, even if not that discoverable, the search can be restricted to open tabs with the '%' filter. And this is tested too. Any other enhancement doesn't looks like blocking this from being fixed. Thus I'm resolving, Blair, if I missed anything, feel free to reopen.