Open Bug 359684 Opened 18 years ago Updated 2 years ago

Highlight search phrase in "Message body filter" search results

Categories

(Thunderbird :: Mail Window Front End, enhancement)

enhancement

Tracking

(Not tracked)

People

(Reporter: sylvain.pasche, Unassigned)

References

Details

(Keywords: uiwanted, Whiteboard: perceived regression from bug 328795 per comment 15)

This is one feature I miss from Evolution. When performing an "Entire Message" search, it would be useful that the search phrase is highlighted in the messages which match the search. The highlighting could be like the "Highlight all" used in the quick search. Probably with another color to differentiate.
we do this currently, at least in 2.0 - I thought we did it in 1.5 as well, but I'm not sure.
This regressed from 1.5.0.7 where that's working. I'll try to find the regression if I've got some time.
Keywords: regression
Severity: enhancement → normal
Version: Trunk → 2.0
Apparently, the regression comes from bug 328795 (In reply to comment #4) > 2) Remove the highlighting code from searchBar.js. We don't need this anymore. > Highlighting is done from the find bar. but highlighting is also used for the message body search. Maybe some code should be restored for this specific highlighting.
It's not clear whether the search being used is the QuickSearch (where you can display the matching messages in the message pane) or Search All Messages (where you need to open a standalone window). Either way, the desired result can be achieved, altho it requires several steps. Quicksearch is easier: select the Entire Message criterion, enter the search string. Select the first message; Ctrl+F, re-enter the search string, click Highlight All. Now you can select another message, or navigate using 'F' and 'B' (or whatever your preferred method is) -- all occurrences of the string will be highlighted in each message you pick, until you close the searchbar. Using the message-search window, you need to re-do the Search Bar for every message you open, since there's no message pane in the search window, and it doesn't abide by the "Open new messages in: an existing window" option (for which I've just opened bug 360292); nor is there a way to navigate the search results using F/B (which is bug 95140). These problems could be finessed by saving the search as a saved-search folder, at which point they're navigable in the 3-pane by selecting that folder.
I was thinking about the QuickSearch situation for this bug report. While the method you mention is a way to achieve the same effect, I find the old behavior more convenient. Anyway, is this new behavior intentional (meaning we should rely on the find bar for highlight in this multi-step process) or not?
I added my vote for the "Highlight in Message" (or "Find in Message") feature to be put back. It did in one step what now requires several. Especially sad is the fact that you have to manually type the same search string twice. If Ctrl+F could automatically pick up the search string from the quickSearch box, the workaround suggested in comment #5 could have actually be very nearly a full fix. Even then, having to use two separate controls and several steps instead of one control and one step, seems to be a regression. An alternative way to deal with this would be to add a "Highlight All" option to the quickSearch itself; or make it a built-in option that turns itself on whenever full-text search option ("Entire Message") is chosen. There could be a menu bar or toolbar option to toggle it off.
(In reply to comment #7) > An alternative way to deal with this would be to add a "Highlight All" option > to the quickSearch itself; Isn't this what was originally done anyway and was over-zealously removed? > or make it a built-in option that turns itself on whenever full-text search > option ("Entire Message") is chosen. There could be a menu bar or toolbar > option to toggle it off. I can see that causing problems for users who have already established/wish to use different FAYT conditions in the message display without things getting confused by Quicksearch interfering. Much simpler to have, as before the regression, separate highlighting controls for each and probably, as suggested in this Bug #359684 #Description, to additionally use different colours if possible.
(In reply to comment #8) > (In reply to comment #7) > > An alternative way to deal with this would be to add a "Highlight All" option to the quickSearch itself; > > Isn't this what was originally done anyway and was over-zealously removed? Not exactly. There used to be two separate options, one (now extinct) "Find in Message" and the other (still exists) "Entire Message". The automatic highlighting across all messages in a list was a feature of the former. It was removed when the "Find in Message" option was removed. I suggest to add just the auto-highlighting back, but this time make it a feature of the "Entire Message" option. Whatever the name of the new resulting quickSearch feature would be, its main value is that it lets you quickly pinpoint your "target" text in a filtered list of messages. The main use case it serves is "find a specific message containig a specific text", and the way it serves it is by filtering out the messages that don't contain your search string, and in the same time instantly putting that search string in context. This is very valuable from usability point of view, and if implemented the right way, it will not be redundant with the Find bar. I propose that the automatic "highlight all" be made part of this quickSearch option; I am not even convinced an explicit option to turn it off is needed (user could just deselect this quickSearch option or clear the search string). In the comment #7, I only suggested coupling the Find control with quickSearch as a workaround (reasoning this perhaps could be easier to do.) In fact, I can see that the Find bar serves a larger variety of use cases and thus gives the user more control over how to navigate and highlight the matches. It is fine if Find uses distinct highlighting color and in general functions independently from the quickSearch.
(In reply to comment #9) Please refer to the discussion at http://forums.mozillazine.org/viewtopic.php?t=578935 There are already several related bugs concerning QuickSearch, 'Entire Message', 'Body', highlighting and FAYT. Apart from the highlighting whose return was requested by the originator, you do appear to be proposing a new, additional facility (such as 'Copy to FindBar' or, incorporating that, 'Quickfind') which, for the health of the code and the user interface, should be kept as a visibly distinct extra function rather than being implemented by entangling and distorting existing ones. Since this current bug is not described as an enhancement request but rather as reporting a 'regression' of 'normal' severity it would seem better to raise your proposal as a new enhancement request.
Assignee: mscott → nobody
(In reply to comment #10) > Apart from the highlighting whose > return was requested by the originator, you do appear to be proposing a new, > additional facility (such as 'Copy to FindBar' or, incorporating that, > 'Quickfind') which, for the health of the code and the user interface, should > be kept as a visibly distinct extra function rather than being implemented by > entangling and distorting existing ones. Since this current bug is not > described as an enhancement request but rather as reporting a 'regression' of > 'normal' severity it would seem better to raise your proposal as a new > enhancement request. No, I am not really asking for "Copy to Find" and such; that was suggested as a possible workaround only (as pointed out in my comment #9). If they add the highlighting to the "Entire Message" option, there's no need to ever have the FindBar involved, and both UIs and their code can be happily kept separate. Yes, could use a different color of highlighting than the FindBar's one. True, you probably couldn't highlight the text in the headers and such (or well, maybe you could?); but showing the highlights in the message Body alone should be sufficient to solidly support a typical use case.
Blocks: 515237
"Entire Message" quicksearch filter has finally been renamed to what it actually is, "Message body filter".
Severity: normal → enhancement
Summary: Highlight search phrase in "Entire Message" search results → Highlight search phrase in "Message body filter" search results
Version: 2.0 → unspecified
So now it should be possible to add back the highlighting of the terms in the message body?
To claify, the meaning of "back" here is that this automatic highlighting used to be available with the (now extinct) "Find In Message" feature; adding it now to the "Message Body" filter would reinstall that feature, albeit on a technically different filter.
Thomas, is this then NOT a regression? (can't be both ENH & regression)
Afasik, _technically_ this is _not_ a regression (see comment 15), but it's surely a _perceived_ regression, in view of workflow then and now: Aim of this bug: - filter messages for word(s) in message body AND - automatically highlight search word(s) in each msg preview of found msgs (to create a context) Former Steps in TB 1.5 (no guarantees, can't test any more) 1 Enter search words into "Entire Message" QuickSearch filter (wrongly labelled, only did "Message Body") 2 from same QuickSearch box dropdown (without retyping search words), choose "Find in Message" * browse through messages in preview -> search words will be highlighted in each found msg (sticky "find in msg", pls correct me if I am wrong, can't test any more) Current Steps in TB 2 and TB 3 (with "Find in message" relocated to Find bar) 1 Enter search words into "Message Body" QuickSearch filter (Entire Msg Filter doesn't exist yet in the current 3.0 release; but we have a fix) 2 Ctrl+F to show Find bar (like "Find in message", but in a different place); 3 retype search words in Find bar (or copy and paste) <- this is the extra annyoing step * browse through messages in preview -> search words will be highlighted in each found msg (sticky "find in msg") Proposed Steps (this RFE) 1 Enter search words into "Message Body" QuickSearch filter (Entire Msg Filter doesn't exist yet in the current 3.0 release; but we have a fix) * browse through messages in preview -> search words will be highlighted in each found msg (automatical sticky "find in msg" for all filters that involve searching msg body). So this RFE combines the best of both worlds with even less steps than before, as comment #15 explains in short. It would actually be a pretty cool enhancement, not very difficult to do, and something I would expect of any decent full text search. ToDo: We need to agree on the last details of implementation (uiwanted). a) separate highlight color for automatical vs. manual "find in msg" (body quick filters vs. find bar) <- that's easy to agree on b) UI for getting rid of automatical highlighting for those who do not want it b1) in general (never highlight when filtering) b2) temporarily (get rid of filters' highlighting for the currently displayed message) b1 and b2 might be combined in a single option, depending on the UI chosen.
Keywords: regressionuiwanted
Whiteboard: perceived regression from bug 328795 per comment 15
Re: Proposed Steps (in comment 17). Yes, that's exactly what I'm looking for! Yes, there needs to be a separate highlight style for the find bar criteria. It will be quite powerful if one could first filter down the list of msgs by a specific "Message Body" text; then scan the msgs in the resulting set for an occurrence of some *additional* text. This is like "search within this results set".
Some UI ideas for getting rid of the highlights. (a) R-click any highlighted word > option to remove the highlights for this search; another option to never highlight when filtering. Downside: once you remove the highlights, you can't get them back until you re-search. Also, how to un-do the "never highlight" option? (b) "Message Body" entry in the QuickSearch filter has a toggle control associated with it (e.g. "Show Highlights / Hide Highlights"). (c) When you enter search words into the "Message Body" QuickSearch filter, this automatically brings up the find bar and replicates those words there. So the highlighting is actually done by the find bar. Users still can replace the entry in the find bar by any other entry, then the new highlights will replace the original ones, but the message filter itself will remain. Admittedly this is an awkward option both implementation-wise and from usability point of view, because the entries in the find bar usually persist until user closes the find bar. This option would wipe out any existing user-set entry and replace it with the automatic entry; so it's against the current model. The up side is that you don't have to overlay two different styles of highlight.
Blocks: 540055
fyi, this is implemented in [TotalQuickFilter](https://bitbucket.org/alta8888/totalquickfilter).
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.