Closed Bug 1248486 Opened 9 years ago Closed 4 years ago

hitting tab too quickly after typing in an address field causes autocomplete to fail

Categories

(Thunderbird :: Message Compose Window, defect)

Product:
Thunderbird
Component:
Message Compose Window
Version:
45 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1659332

People

(Reporter: jc.bugzilla, Unassigned)

References

Details

Attachments

(1 file)

Example address fill with and without pause before tab press
(deleted), image/gif
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:44.0) Gecko/20100101 Firefox/44.0 Build ID: 20160210153822 Steps to reproduce: Begin creating a message with multiple recipients. Go to one of the addresses that is not the final address in the list. Type the beginning of a term you intend for Thunderbird to autocomplete quickly, then hit tab. Actual results: Autocomplete fails. Expected results: Address should autocomplete as expected. This is similar to Bug 1012397 except that the failure only occurs when hitting tab does not advance to the next "section" of the message compose screen but rather to another entry in the recipient list (the next "section" is usually the Subject field, but failure also occurs if you are not on the first recipient in a multiple recipient list and shift-tab too quickly after partial address entry). Basically it seems like tabbing only triggers autocomplete after quick character entry if the tabbing results in a change of focus away from the recipient list widget. This also might be related to how, in Bug 1151520, hitting Enter in a recipient list will fail to trigger autocomplete if Enter is hit too quickly after entering part of an address book entry. Perhaps the autocomplete fix implemented in Bug 1012397 only works when the recipient list loses focus?
You filed this bug against version 45. Did version 38 and 31 also fail for you?
Flags: needinfo?(jc.bugzilla)
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #1) > You filed this bug against version 45. > Did version 38 and 31 also fail for you? Hi, Yes, I just checked them and they both fail in the same way.
Flags: needinfo?(jc.bugzilla)
I think this is potentially a duplicate of Bug 1012397, although that was marked as complete. I can confirm that the behavior remains in Thunderbird 45. If you type enough characters to resolve a name and then tab out of the field before the resolution occurs, the resolution will appear a few tiny moments *after* the focus has already changed. Therefore, the field that was just resolved never sees a blur event and never cleans up its resolution proposal (e.g., "fooba >> Foobar@mozilla.org")
My apologies! You mentioned that in your bug and were even prompted to create this as a separate bug.
Keywords: perf
Whiteboard: [dupme?]

Can you still reproduce this?

Flags: needinfo?(themoz)
Flags: needinfo?(jc.bugzilla)
Keywords: perf
Whiteboard: [dupme?] → [closeme 2021-04-11]

Yes, easily.

Assume I have an address in my address book for the email address I am using at Bugzilla, themoz@..., and that is the suggestion that Thunderbird will provide if I type "them".

If I type that "them" and then pause to wait for the suggestion to appear, then press tab, the suggestion will be confirmed and I will be ready to type another recipient.

If, instead, I type "them" and immediately press tab—that is before the suggestion is provided—Thunderbird will accept an address of literally the letters "them" (marked in red because this isn't a known address).

I will attach a GIF animation of the difference, immediate tab-press example first, followed by a pause-then-tab example.

The desired effect is that Thunderbird executes a name-lookup suggestion call at the time of pressing tab, regardless of whether it had been given time to provide a suggestion before the tab was pressed, and that the first suggestion it finds in that call is immediately confirmed.

Flags: needinfo?(themoz)

See my previous comment for a description of this example GIF animation.

Same exact thing for me. Very reproducible.

(In reply to Brian Hauer from comment #6)

Yes, easily.

Assume I have an address in my address book for the email address I am using at Bugzilla, themoz@..., and that is the suggestion that Thunderbird will provide if I type "them".

If I type that "them" and then pause to wait for the suggestion to appear, then press tab, the suggestion will be confirmed and I will be ready to type another recipient.

If, instead, I type "them" and immediately press tab—that is before the suggestion is provided—Thunderbird will accept an address of literally the letters "them" (marked in red because this isn't a known address).

I will attach a GIF animation of the difference, immediate tab-press example first, followed by a pause-then-tab example.

The desired effect is that Thunderbird executes a name-lookup suggestion call at the time of pressing tab, regardless of whether it had been given time to provide a suggestion before the tab was pressed, and that the first suggestion it finds in that call is immediately confirmed.

Flags: needinfo?(jc.bugzilla)

Hi Joey, thanks much for updating us and providing the screencast, that's super helpful! :-)

Ok, this is reported against TB versions 68 and before with old addressing area, so technically this bug would be expired, but we don't have that resolution available.

Let's note that remaining with a stale proposal fooba >> foobar@example.com is no longer seen in the screencast.
What I am seeing in the screencast of TB 78 is exactly what Alex and I are trying to fix in bug 1659332, so let's dupe to that with a bit of fuzzy factor.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
Whiteboard: [closeme 2021-04-11]

Thank you for the update. I'm going to hop over to spectating and cheering on the eventual fix of bug 1659332!

(In reply to Thomas D. (:thomas8) from comment #9)

Hi Joey, thanks much for updating us and providing the screencast, that's super helpful! :-)

Just to be clear: Brian provided the screencast and the details; I just said "me too!" Want to make sure he gets credit as it was so thorough.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: