Closed Bug 787608 Opened 12 years ago Closed 10 years ago

Address autocomplete should be smarter with leading spaces entered into composition's recipient pane

Categories

(Thunderbird :: Disability Access, enhancement)

15 Branch
enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 31.0

People

(Reporter: aaron, Assigned: sshagarwal)

References

Details

(Whiteboard: [STR: comment 1][Fixed by Bug 558931])

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20100101 Firefox/15.0 Build ID: 20120824154833 Steps to reproduce: I am a developer with no use of my arms or hands. This necessitates that I use DragonDictate in order to communicate with my computer. However, unless I specifically speak the text "no space" 1st, a space will precede each word spoken. Unfortunately, when I enter an address in the address bar, when composing an e-mail, a leading space we will break the auto complete functionality. Actual results: Adding a leading space to a name in the address bar when composing an e-mail causes the auto complete functionality to not work. Expected results: The auto complete functionality should ignore any extra white space in the address when searching the address book.
(In reply to Aaron Winborn from comment #0) Aaron, thanks for raising your issue here. Let me try to describe your request more clearly: STR: 1. Have AB entry with these properties: First Name: " LeadSpace" (leading space, but without quotes!) Last Name: "Test0409" 2. Compose new message 3. In recipient field, subsequently type one of these: a) "Lead" (all of these without quotes) b) " Lead" c) "Test0409" d) " Test0409" 4. watch autocomplete sugggestions Actual results: > Adding a leading space to a name in the address bar when composing an > e-mail causes the auto complete functionality to not work. Not really. It just quite predictably as expected: a) "Lead" -> due to bug 558931, finds nothing, but should find something b) " Lead" -> correctly finds match with leading space c) "Test0409" -> correctly finds match d) " Test0409" -> "correctly" does not find match, because there are no AB entries that contain " Test0409" (with leading space). Expected results: > The auto complete functionality should ignore any extra white space in the > address when searching the address book. Iow, this RFE requests different behaviour for d) d) " Test0409" -> should ignore the leading space entered and find match for "Test0409" Notes on current behaviour: 1) We currently allow leading spaces in AB fields, so: 2) Users can use leading spaces to alphabetically sort entries with leading spaces before all other entries (which seems a legitimate use case) 3) Users can use leading spaces in address autocomplete to retrieve such entries with leading spaces Caveats: 4) As long as notes on current behaviour (1-2) apply, we need to ensure that 3) above continues to work, iow: b) " Lead" must find matching existing entries with leading space So we cannot just entirely ignore the leading space. However, I can think of two safe ways of eliminating the problem of this RFE: Possible Solutions: S1: " Lead" will find matching entries with leading space; only if there are none such, try finding matches for "Lead" without leading space. S2: " Lead" will return matches with leading space first; then additionally, any matches for "Lead" without leading space. Both of these solve reporter's scenario. Recommended Solution: I think we could safely do S2, in line with more flexible search approach of 558931.
Severity: normal → enhancement
OS: Mac OS X → All
Hardware: x86 → All
Summary: Leading spaces in address breaks auto complete → Address autocomplete should ignore leading spaces entered into composition's recipient pane
that sums it up nicely. Thanks!
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Address autocomplete should ignore leading spaces entered into composition's recipient pane → Address autocomplete should be smarter with leading spaces entered into composition's recipient pane
Whiteboard: [STR: comment 1]
Aaron, bug 529584 and bug 558931 have changed/improved the landscape for recipient autocomplete matching behaviour. Searching for "foo" will now find even those odd cases where contact's name properties have " foo" with leading space (everything without quotes unless otherwise stated). We also trim/ignore all extra spaces from the search input: Bug 558931, attachment 8412767 [details] [diff] [review] First leading/trailing spaces: > let fullString = aSearchString && aSearchString.trim().toLocaleLowerCase(); Then extra inner spaces: > // Array of all the terms from the fullString search query > // (separated on the basis of spaces). > let searchWords = fullString.split(/\s+/); Searching for " foo bar " is trimmed to "foo bar", and then searches for "foo" AND "bar". So this solves Aaron's usecase, where he dictates "foo", DragonDictate converts that to " foo", but TB will still just search for trimmed "foo" and find autocomplete matches for that. (As a sidenote, DragonDictate might also be smarter to not add spaces where they aren't needed). Aaron, pls confirm if this works for you now.
Status: NEW → RESOLVED
Closed: 10 years ago
Depends on: 558931
Resolution: --- → FIXED
Whiteboard: [STR: comment 1] → [STR: comment 1][Fixed by Bug 558931]
Target Milestone: --- → Thunderbird 31.0
:P
Assignee: nobody → syshagarwal
Yes, Suyash is our hero for making TB smarter! :p
You need to log in before you can comment on or make changes to this bug.