STR 1 global "search all messages" for "search terms" 2 from faceted search results, user wants to modify the current search terms (a frequent scenario in case of spelling mistakes etc.) actual - cursor is in global search box (good), but - need to re-type all of the search terms into global search box expected - search terms should stay in the global search box - search terms should be highlighted in global search box, with cursor at the end of the terms -> User can easily: a) modify/correct existing search terms by pressing any caret moving key (Cursor, POS1, END etc.) b) replace existing search terms with new search terms by just typing (will overwrite highlighted old search terms) This used to work somewhere along the way of 3.0.x and got lost -> regression

Bryan, Wayne -> feedback? Showing the current search terms in the global search box on top of faceted search results (as proposed in this bug, and as we used to do until recently) would be a major usability improvement when it comes to refining / correcting search terms of existing global search results. No disadvantages that I am aware of (see comment 0). Regression, easy to fix. In support of fixing this regression, note that we currently do *not* open a new search tab when user enters new search words in search box above faceted search results - which is further proof of the underlying theory of this bug that we offer the search box for modifying the /existing/ search terms/results on the same tab (just as he can modify other facets). So why make it unnecessarily hard to modify existing search terms?

I agree this is probably a regression. tested with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a6pre) Gecko/20100621 Shredder/3.2a1pre Do you have a sample regression range? My *guess* would be it started with the "search messages" changes that accompanied the landing of the "new" quick filter. shortly before 3.1 rc1?

Please set wanted-thunderbird+ for this bug. Excellent cost-benefit ratio: This is easy to fix, probably about a one-liner, yet big improvement for anyone who wants to refine their global search without starting all over again.

agree, as a regression, this should be wanted-thunderbird+

didn't fix a bug in a long time, what do i have to do to get a review? =)

Comment on attachment 524663 [details] [diff] [review] fixes the bug in searchBar.js (sets the search value when opening a new tab.) Just set a reviewer, helping and hoping standard8 will be able to review. :)

Comment on attachment 524663 [details] [diff] [review] fixes the bug in searchBar.js (sets the search value when opening a new tab.) iirc asuth wrote this code, so he's probably a better reviewer.

Comment on attachment 524663 [details] [diff] [review] fixes the bug in searchBar.js (sets the search value when opening a new tab.) Yup, I see the regression, and this bug fixes it. Thank you! I have just landed this with a minor change to predicate the decision to look in searchString on the tab mode so that we don't accidentally pick up things from extension tabs that use "searchString" as one of their defining fields. http://hg.mozilla.org/comm-central/rev/896dc129f9b5 No test is required in this case because we lack test coverage for this space and the cost/benefit favors just landing this.

Thank you, everyone involved!!! From the reporter of this bug.