User:David Regev/Firefox Search, Revamped

Firefox Search, Revamped:
How to make Firefox’s search capabilities more helpful

The following is a workflow that I would like to see made possible in Firefox. The idea here is for Firefox to be as helpful as possible without getting in the way. The goal is to increase efficiency when searching (and, more importantly, finding). I will presume that Ubiquity is being used for conducting searches, as it is already far more efficient than the standard search mechanisms (such as the Search bar).

The Desired Workflow

1. Bob searches Google for [foo bar].
2. Bob clicks on one of the search results.
3. The following Magic happens:
   1. The page scrolls down swiftly to the first instance of either foo or bar, placing said instance centred in the window and highlighting it uniquely.
   2. All instances of foo and bar get highlighted, each term with its own colour (a la Google Cache).
   3. The Find bar slides into view, with [foo bar] as its text, allowing Bob to find other instances of foo and bar easily.
   4. The highlighting slowly fades away, followed by the Find bar sliding away, thus returning the page to normal after 15 seconds or so.
   This allows Bob to concentrate on the information Firefox has now helped him locate more quickly.
4. Bob continues browsing, eventually clicking Back until he finds himself back at the search results page.
5. Bob middle-clicks on a different result, putting him in a new tab.
6. Magic occurs for the second time.
7. Bob changes the Find bar text to ["foo bar"].
8. Magic occurs for that phrase. Specifically, Firefox conducts a lazy search on the phrase as one search term, ignoring punctuation and diacritics. E.g., even ‘foö, bár’ is matched.
9. Bob switches back to the previous tab and brings up the find dialogue.
10. The find text still shows [foo bar], since that text is tab-specific.
11. Bob conducts a navigational search on Wikipedia for [foobar].
12. Bob lands directly on the foobar page, bypassing any search results altogether. Magic does not occur.
13. Bob opens the Find dialogue, revealing [foobar] as it text.

Note how much is done to help Bob find what he seeks with as little extra work for him as possible, all without getting in the way of his goals. In order to make this workflow possible, certain features must be implemented.

The Desired Features

1. When one submits a search (whether via GET or POST), it should be detected automatically and the search text copied to the Find dialogue. See bug 270310 and bug 264123.
   • This should occur only on submission, and not when the search results page is incidentally revisited (via Back/Forward).
   • This should require no configuration.
   • SearchBox Sync does this partially for the Search bar.
2. Whenever a search result is chosen, Magic occurs:
   1. The page automatically starts scrolling down swiftly to the first instance of a search term, until that term is centred in the window and is uniquely highlighted. This scrolling may be interrupted by the user. See bug 171237.
   2. Every instance of the search terms is highlighted, each term a different colour. See bug 240432 and bug 342101.
   3. The Find bar slides into view immediately.
   4. This highlighting gradually fades away, with the fade taking approximately 15 seconds to complete. At the same point, the Find bar also slides away. See bug 325234.
   • The fade countdown gets reset if the Find dialogue is used, restarting as soon as the dialogue is inactive again.
   • This should occur only on a search result link being clicked, not when a result page is incidentally revisited (via Back/Forward).
   • This occurs only on the page after a search results page and not on any other page, nor after navigational searches (such as on Wikipedia).
   • SearchWP does this highlighting for the Search bar.
3. Similarly, whenever the Find dialogue is called, Magic also occurs. The page does not scroll, however, until the Find text is modified.
   • This would make highlighting completely automatic. The modal ‘Highlight all’ button would be obsolete. So would the Find bar’s Close button.
4. Find should perform a lazy search:
   1. Any term matches (like with a Google search), rather than the exact string being used. See bug 343118.
   2. Phrases in quotes match only when together (as one term).
   3. Punctuation and diacritics are always ignored, even in phrase searches. See bug 442070 and bug 202251.
   4. This can be overridden by a strict mode that matches for the exact string in a case-sensitive manner. This mode replaces the current ‘Match case’ mode. See bug 269442.
5. The Find text should be tab-specific (to retain search context). See bug 248955.
   • A spawned tab, however, copies over its parent’s Find text.
6. Nice to have: Double-clicking on a search term should centre the next instance of that term.
   • SearchWP does something like this for the Search bar.

Note: I have also summarized these features in bug 565552.