998801 - Composition find bar: implement "Whole word only" option button

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, enhancement)

Description

[Thomas D. (:thomas8)]

+++ This bug was initially created as a clone of Bug #530629 +++

STR

1 compose msg having this sample text:
air airbrush air airy air airbus air

2 in msg compose, press Ctrl+F, type "air" into "Find in page" input, press enter to start searching
2a you want to *find* occurences of a *whole word* like "air", but not partial matches from composites like airbrush, airy, airbus etc.
2b click "Replace..." button on findbar and fill dialog as you want to *replace all* occurences of a whole word like "air" with "wind", but not partial matches from composites like airbrush, airy, airbus etc.
(Note that such scenarios are much more likely in some other languages like German where composite words are much more frequent than in English.)

actual

2a there's no way to search for "whole word" matches only, so you'll also find all the partial matches on the way (false positives)

2b there's no way to do "Replace all" for "whole word" matches only, so your choice is between "Replace all" and messing up your whole text when partial matches are wrongly replaced, or replace one-by-one to skip false positives manually.

expected

2a on find bar, there should be a "Whole word only" option to allow easy exclusion of false positives of partial matches

Proposed implementation/UI

We might have to implement the behaviour in the underlying search algorithm. UI-wise, on find bar, add a "Whole word" button between "Match case" and "Replace..." button, directly before the separator.

Reasons in favour of this RFE:

1) ux-efficiency: if you're just after "whole word" matches but not partial matches, having to check each occurence manually to avoid false positives is annoying and very inefficient. With the "whole word only" option proposed here, all those false positives from partial matches could be easily skipped programmatically if the user so choses.

2) ux-error prevention: not offering "whole word" option can lead to errors when users just use "Replace all" anyway (unintendedly replacing false positives), and manual verification (alternating between replacing desired "whole word" matches and skipping false positives) is also error-prone

3) external ux-consistency: all other word processing applications have "Whole word only" checkbox option in Find and Replace dialog, and editor certainly acts as a word processor here as we compose written documents (there's no substantial difference between e.g. composing a letter in Word or a message in TB).
Some well-known word processing apps that have "Whole word only" option (for screenshots, pls follow the links below):
- M$ Word [1]
- Open Office Writer [2]
- WordPad (even simple word processor already has this!) [3]

[1] http://img.tekgazet.com/dir1/word_replace_format01.png
[2] https://wiki.openoffice.org/w/images/2/2e/FR-box.png
[3] http://the-edmeister.home.comcast.net/~the-edmeister/images/cloning/chrome-rdf_wordpad-replace_dialog_box.png

Comment 1

[Thomas D. (:thomas8)]

As described in comment 0, this will be highly useful, practically required for any serious "Find and Replace" UI, so ideally this should land before or with bug 998343 (inline Find & Replace bar).

Note that this option is used for the finding part of "Find & Replace", so it should be on the find bar because it's also applicable for plain Find (without replacing).

Comment 2

[Thomas D. (:thomas8)]

Bug 16750 is same request for filters, with a bit of supporting philosophy in Bug 16750 Comment 1.

Comment 3

[Thomas D. (:thomas8)]

Can somebody comment if the backend of find bar (OR find and replace dialogue?) already supports "whole word" behaviour?

Comment 4

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #3)
> Can somebody comment if the backend of find bar (OR find and replace
> dialogue?) already supports "whole word" behaviour?

Apparently this is not yet supported by the toolkit and browser backend of findbar, although it's very popular with 18 dupes and 40+ votes:

Bug 269442 - Add Find Whole Word/ Find Exact String Option to Find Toolbar
Bug 481513 - javascript window.find() ignores wholeWord parameter

Comment 5

[Suyash Agarwal (:sshagarwal)]

As far as I could look, the changes are to be made finally in
http://mxr.mozilla.org/comm-central/source/mozilla/embedding/components/find/nsFind.cpp

So, is this okay?
If yes, please let me know. I'll investigate further.

Thanks.

Comment 6

[Blake Winton (:bwinton) (:☕️)]

That would be okay for fixing one of the two bugs Thomas D. mentioned above.  But, since we need those bugs to get fixed before we can fix this bug, I would say sure, go for it!  (But you should probably leave your questions and comments in bug 481513. ;)

Comment 7

[Thomas D. (:thomas8)]

(In reply to Suyash Agarwal (:sshagarwal) from comment #5)
> As far as I could look, the changes are to be made finally in
> http://mxr.mozilla.org/comm-central/source/mozilla/embedding/components/find/
> nsFind.cpp

Yes, that's the right file, but I've already succeeded to motivate someone to fix this for toolkit in Bug 269442 - Add Find Whole Word/ Find Exact String Option to Find Toolbar.

The patch there, attachment 8447319 [details] [diff] [review], is pretty near completion (once again), so all we need to do now is poke the patch owner some more to ensure that this actually lands. After that (or perhaps simultaneously), we can start hooking that functionality up with TB UI.

Comment 8

[Suyash Agarwal (:sshagarwal)]

(In reply to Thomas D. from comment #7)
Okay cool! So, we'll have a look at this once that gets fixed.

Thanks.

Comment 9

[Thomas D. (:thomas8)]

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #7)
> I've already succeeded to motivate someone
> to fix this for toolkit in Bug 269442 - Add Find Whole Word/ Find Exact
> String Option to Find Toolbar.

As a direct result of my persistent advocacy and poking, this was fixed in toolkit Bug 269442 and is now available in TB's find bars, too, both in message reader and composition.