using the auto-complete to choose searches that match all of your terms or any of your terms will be bit confusing for many users. Faceting for the most part is about pruning results after the fact and this upfront choice doesn't present enough information for a person to decide if the AND is going to be too restrictive. At the same time a good search system should handle the ANDing and ORing of terms for the user mostly without their explicit knowledge. Future systems could realize small numbers of results and offer to expand the search by ORing the terms. Often when search results are large ORing the terms is a useless operation that only expands the result set beyond what was already usable.
setting myself up for failure
or setting david up FTW!
Created attachment 402966 [details] [diff] [review] patch v1 This patch needs to land after the patch in Bug 518946, as I'm removing the back-end logic to deal with AND/OR differences (we just do AND) (and that patch removes the only client) In addition to the change specified in comment #0, I'm also: 1) increasing the # of characters for which we offer full-text search to 3. 2) using a slightly tweaked version of the "build-phrases-through-quotes" algorithm in msg_search.js, as suggested by asuth. The only difference is that I'm stripping commas from the term list, as otherwise they pollute the display. The backend strips commas anyway so there's no non-visual impact. This means you can search for "david loves" and it will return messages that include "david loves emily" but not messages that include "emily loves david". This patch does change a string ID.
Created attachment 402990 [details] [diff] [review] patch v2 r=asuth with the attached minor changes. Our reuse of richlistitems was running into trouble when the type of a display node was changing. Because of the change in the minimum count for the autocomplete hint, such a transition could occur during the change from 3 letters to 4 letters where an identity XBL binding would think that a search string was an identity. This would throw an exception and result in wackiness. We now no longer reuse items and change the height adjustment logic slightly because we use multiple types of display widgets.