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)
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.
Comment 1•12 years ago
|
||
(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
Reporter | ||
Comment 2•12 years ago
|
||
that sums it up nicely. Thanks!
Updated•12 years ago
|
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]
Comment 3•10 years ago
|
||
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]
Updated•10 years ago
|
Target Milestone: --- → Thunderbird 31.0
Comment 5•10 years ago
|
||
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.
Description
•