Thunderbird 31 regression: changing focus with <TAB> in compose window during address autocompletion

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release)
Build ID: 20140715214335

Steps to reproduce:

After CTRL+N keystroke when the typed search term resulting correct autocompleted e-mail address from address book, TAB and SHIFT+TAB keystrokes resulting present a new to: text box.

Actual results:

Expected result before Thunderbird 31.0:
Previous versions after CTRL+N keystroke when a search term resulting correct autocompleted e-mail address, if the user press TAB and SHIFT+TAB keystrokes, Thunderbird right jump the Subject text box or the previous address type combo box with possible set address type (to: CC, BCC, etc).
Of course, if in to: text box after autocompletion the user press ENTER key, right to presenting a new to: text box.
I using Thunderbird with screen reader and now more time happening me to I type the subject with the new to: text box (more time forgot with subject text box need pressing two TAB keys). :-):-)

With Thunderbird 33.0a2 and 34.0A1 version affected too, I downloaded following place the test version:
ftp://ftp.mozilla.org/pub/thunderbird/nightly/latest-comm-aurora/thunderbird-33.0a2.en-US.linux-i686.tar.bz2
ftp://ftp.mozilla.org/pub/thunderbird/nightly/latest-comm-central/thunderbird-34.0a1.en-US.linux-i686.tar.bz2

Created attachment 8462337
Video to show the issue with various situations

This video shows the issue with various situations.
When first time pop up the message dialog, I simple typed an e-mail address.
After this, press SHIFT+TAB keystroke. Ideal situation possible setting the typed e-mail address type with any type (to:, CC, bcc). Now, the caret land the new empty to: field. So, I need pressing three SHIFT+TAB keystrokes to change the first e-mail address type with bcc or cc type, and after this, need jumping more tab keys the subject field.

The second case simple typed an e-mail address, and two keypress need using to jump the subject field.

Attila

just checked. Confirm.

Just to clarify the expected results a bit:

1. Tab should put the selection in the *Subject* line (and not create a new To/CC/BCC address line).

2. Shift+Tab should put the selection on the To/CC/BCC drop-down-button *before* the current address.

Peter, correct with you wrote. This is the expected result with need restore if this is possible.
Possible fixing this issue both Thunderbird 31.0 and 33X/34.x releases?

Attila

If it started in version 31, this is also regression of bug 959209

Modifying summary (tab-shift works like before afaikt), and confirming for discussion.
This change was discussed in bug 959209 comment 6. I'm not sure I'd consider it a bug, but I'm open for arguments.

Created attachment 8463013
bug1043784_tab_adds_address_row.patch

Restore the earlier behavior of not adding an addressing row when tabbing or selecting from autocomplete, but only for ENTER.

Just FYI, tab in To: goes to Subject: when autocomplete fails (which happens in TB 31 rather often, autocomplete seems to have become slower, or am I dreaming?) It is only afer autocmplete, that tab creates another To: -- still, the subject of this report holds, so maybe I am preaching to the choir…

(In reply to Magnus Melin from comment #7)
> tab-shift works like before afaikt

No, it does not. Shift+Tab used to put the selection on the To/CC/BCC drop-down-button before the current address.

This was very useful because when entering an address, one presses ENTER, and the selection goes to the next address line. After selecting the second address, being able to press Shift-Tab to change the To/CC/BCC is VERY useful because the second recipient is often a CC, and the third recipient is often myself (a BCC). Please fix this frustrating regression (and re-fix the Subject of this bug).

(In reply to Peter Lairo from comment #10)
> (In reply to Magnus Melin from comment #7)
> > tab-shift works like before afaikt
>
> No, it does not. Shift+Tab used to put the selection on the To/CC/BCC
> drop-down-button before the current address.

It does work like that for me (on linux), so I'm not sure what you're seeing.

On Windows 7:
1. type part of a name
2. select one of the matches via keyboard up/down arrows (or just accept the default selection)
3. Press SHIFT+Tab

Actual Result:
- A new address line is created, and the cursor is placed in it (the selection moves *forward*).

Expected Result:
- The selection should move *back* to the To/CC/BCC button of the address that was just selected.

Oh I see what you mean now (you mean during the selection process, before a new row was added). The patch (attachment 8463013) fixes that, it's just a side effect of adding the row.

*** Bug 1048536 has been marked as a duplicate of this bug. ***

*** Bug 1046923 has been marked as a duplicate of this bug. ***

At second thoughts, I'm not very convinced of the behaviour proposed in this bug, although I do sympathise with its purpose of streamlining the tab circle for this particular scenario (so I'm a bit in between, no too strong feelings about this so far...). So I'm offering some thoughts for wontfix.

Please note that all of these problems will go away with the new recipient area design per bug 440377.

Behaviour proposed by this bug:
If we ignore the old behaviour (whatever it was), currently as of TB 31 this bug wants to remove the tab stop at the empty addressing line which follows the user-filled addressing lines (or to not even create that empty line at all when you confirm an autocomplete entry with tab).

Alternative behaviour proposed by me:
Instead, I propose that we keep the tab stop at the empty addressing line, and pressing tab again on the empty line then moves to subject (one extra stop, as in current TB 31). Here's why I think this is better:

1) We already have a potentially unlimited number of tabstops for every filled address line - just one more for the blank line doesn't really hurt, but it's actually quite useful (more below).

2) Given 1) where tab goes through each and every filled address line, it really comes as a surprise that the empty line, the only UI element where you are supposed to enter more addresses, is skipped - in fact, that's almost an accessability issue (because tab is the fine-grained focus circle that shouldn't skip anything relevant). And I think in both old and current design, we always try to keep one empty line to show users where the next address must go (as long as we still have this old and clumsy recipient area design).

3) Major point: If there's no tab stop at the empty line (or we don't even create an empty line), what are keyboard user's alternatives to get there after the fact?

Suppose I'm already in subject and forgot another recipient which I want to add now. Suppose the blank recipient line is already there because I used Enter before.

- Current behaviour (TB31) = my proposal: Shift+Tab (back to the empty recipient line), start typing recipient. Easy.
Current focus ring: Filled address line 1 > ... > Last Filled address line >
                    Blank address line > Subject

- Behaviour after this bug: Shift+Tab (back to the last filled recipient line because we didn't add a blank line), and then what? (intuitive try: TAB! - fails after this bug)
Proposed focus ring: Filled address line 1 > ... > Last Filled address line >
                     Subject

Same for forward tab cycle: Start out somewhere, tab forward until you are on the last filled address line, and then what? (intuitive try: TAB! - fails after this bug)

So the only way to get into the blank line, or add a blank line at all, is to somewhat unintuitively use ENTER on an already existing and confirmed address line. Why should I have to do that? There's nothing to confirm, and I'll actually be afraid that re-confirming with ENTER might somehow change my existing entry (you never know with autocomplete). I think that odd feeling is because the intuitive way of moving focus around across existing things without touching anythi...

TL;DR of comment 16:

The "blank recipient line" after filled recipient lines is an important UI element because it's the default way of adding new recipients.

Therefore:
- blank line should always be created after confirming an address (regardless if confirmation occurs with TAB or ENTER)
- blank line should always be a tab stop

To be consistent, I think my proposal also requires that when you just enter a new address manually, say you just type 'Peter <email address hidden>', then press TAB, we should first create a new blank address line, then the next TAB goes into subject.

Imo the new flat design which emphasises the single-line address input fields even more than before (by white background on focused line) actually supports the notion of each line being an UI element in its own right (at editing time). Whereas before the new design, it looked more like a single notesheet where you just enter multiple lines with Enter. Iow, users might be MORE likely to use tab for just getting into the next (blank) line with our new design.

(In reply to Thomas D. from comment #16)
> At second thoughts, I'm not very convinced of the behaviour proposed in this
> bug, although I do sympathise with its purpose of streamlining the tab
> circle for this particular scenario (so I'm a bit in between, no too strong
> feelings about this so far...). So I'm offering some thoughts for wontfix.
>
> Please note that all of these problems will go away with the new recipient
> area design per bug 440377.

Well... I guess that depends (lots of complex descriptions of behavior in there but I couldn't work out exactly what the final result would be)...

I actually like the old/original behavior, and I won't - or will only very rarely - put multiple addresses on one line.

I have no problem with, and agree that Thunderbird should fully support multiple addresses per line like all other email apps do, but there is no reason we can't have both the old behavior and the new.

They are really two totally different issues anyway.

The old behavior used ENTER to add a new address line, and TAB to go to the SUBJECT field.

Old way:

1. Add addresses
2. When done, TAB to subject field

Now with the bug:

1. Add addresses
2. Hit TAB
3. Hit DELETE to delete the blank line (I don't like it, it just looks wrong to me, and if I needed another one, I just clicked at the end of the last one and hit ENTER)
4. Hit TAB again to go to the Subject field

Note: I guess I would be fine with this bug being amended such that hitting TAB adds a blank address line BUT still just jumps straight to the Subject field instead of having to hit TAB again.

Reason: I am constantly entering something in the address field meant for the subject, then encounter an error when sending. It is extremely annoying.

Again - there is no reason that I can see to force us to have to hit TAB twice.

So:

Hit TAB - add blank address line AND jump to subject field
Hit ENTER, go to another address field.

More context (looking at FF and other spots in TB): Bug 97918, Bug 520040, ...

(In reply to Thomas D. from comment #16)

Although I disagree that TAB should add and enter a new address line (because it doubles the number of key-presses needed to finish entering an address, and ENTER already adds a new address line), I can see the reasoning for it (the edge case of a novice user NOT using their mouse for everything).

My main issue right now is that SHIFT+TAB doesn't go to the To/CC/BCC button BEFORE the current address anymore.

+1, SHIFT+TAB need jumping back the address type combo box, not adding a new address field.
For example I better would like to TAB key not add a new address field after typed the autocompleted e-mail address, similar if a typed full new e-mail address not have in the address book.
Now, tab key navigation not working consistent in Thunderbird 31.0 and higher development versions message compose window.
For example if I typing an e-mail address with not have in the address book and press TAB key, the caret correct jumping the subject field. This is the expected result both autocompleted e-mail addresses and in address book not have e-mail addresses.
SHIFT+TAB key combination works good, after I typed the e-mail address with not have in the address book and press SHIFT+TAB key combination, the caret jumps to the address type combo box.
This is the expected result with autocompleted e-mail addresses too.

Please not give won't fix flag this problem if this is possible.

Attila

Now happening following thing if for example typed the second e-mail address and want changing the address type:
1. Press SHIFT+TAB key.

I forgot a thing:
If more e-mail addresses is typed, after the last e-mail address need landing the caret with the subject field and not create a new address edit field.
Between typed e-mail addresses SHIFT+TAB key combination need switching the address type combo box and the previous typed address.
Peter, if need, please complete my two comments, possible my english language descriptions is not always good.

Attila

(In reply to Peter Lairo from comment #20)
> My main issue right now is that SHIFT+TAB doesn't go to the To/CC/BCC button
> BEFORE the current address anymore.

(In reply to Attila Hammer from comment #21)
> +1, SHIFT+TAB need jumping back the address type combo box, not adding a new
<snip>
> Please not give won't fix flag this problem if this is possible.

Guys... that is a DIFFERENT bug... related, maybe, but still different.

Please create/open a NEW bug for it.

Charles, the SHIFT+TAB related issue I reported with separate report in bug 1051564 and wrote two testcases with shows the different working method.
The tab key related issue and inconsistency possible fixing in 31.0 and higher development versions?
Two testcases, first testcase reproducing the problem:
1. Press CTRL+N keystroke.
2. Type an e-mail address with have your address book.
3. Press TAB key.
Expected result:
Caret need jumping the subject text box and not adding an empty address type.
Actual result: presenting a new empty to: text box. Second tab key jumping the subject text box.

Second testcase shows what happening if an e-mail address not have the address book:
1. Press CTRL+N keystroke.
2. Type <email address hidden> address.
3. Press TAB key.
This situation the caret jumps correct with the subject line and Thunderbird correct not adding an empty to: text box.

For example with screen reader users important the consistent working method.

Attila
Attila

While I read and understand Thomas D.'s comments about how TAB should create a new 'To' box, I respectfully disagree. I believe this issue is purely a regression and should be fixed to retain the old behavior. AFAICT, there was never a conscious UI decision to change the long-standing behavior of Thunderbird's compose window in this case, and so it should go through a proper UI review if it's going to be changed.

Additionally, the current behavior is extremely inconsistent. If I type an address that is NOT in my autocomplete list, then TAB still works like it used to. I see this as yet another sign that this is a regression, not an intentional change.

So please, let's consider this report a regression and get it fixed as such. This issue has seriously annoyed me (and presumably others on this ticket), and I'm just happy to find that someone else cared enough to report it already.

Thanks!

A huge, huge +1 to Brian's much more logical reasoning to fix this back to the old behavior.

(In reply to Brian Norris from comment #25)
> While I read and understand Thomas D.'s comments about how TAB should create
> a new 'To' box, I respectfully disagree. I believe this issue is purely a
> regression and should be fixed to retain the old behavior. AFAICT, there was
> never a conscious UI decision to change the long-standing behavior of
> Thunderbird's compose window in this case, and so it should go through a
> proper UI review if it's going to be changed.
>
> Additionally, the current behavior is extremely inconsistent. If I type an
> address that is NOT in my autocomplete list, then TAB still works like it
> used to. I see this as yet another sign that this is a regression, not an
> intentional change.
>
> So please, let's consider this report a regression and get it fixed as such.
> This issue has seriously annoyed me (and presumably others on this ticket),
> and I'm just happy to find that someone else cared enough to report it
> already.
>
> Thanks!

Magnus, I'm for the old behavior and you should ask for review.

ENTER has to go to the next addressing field and TAB to the subject. It makes no sense to have two different keystrokes making the same. ENTER is like a CR saying "go to next line" which is fine. TAB says "go to the next widget" and the next widget is the subject field as the addressing widget with it's multiple lines is one widget.

(In reply to Thomas D. from comment #16)
> At second thoughts, I'm not very convinced of the behaviour proposed in this
> bug, although I do sympathise with its purpose of streamlining the tab
> circle for this particular scenario (so I'm a bit in between, no too strong
> feelings about this so far...).

As indicated in my comment 16, so far I'm not so certain about this and no strong feelings involved, so I won't get in the way of fixing this bug unless new compelling findings suggest otherwise.
In fact, my comment 16 isn't very good; it's partly inaccurate because I mixed up two different scenarios. That's also because we don't have clear STR, and there are a lot of implicit assumptions made in this bug which should be explicit to avoid misunderstandings.

STR
1 compose new msg
2 in exactly the last empty recipient row (with set recipient type), type a searchword which triggers at least one autocomplete suggestion: e.g. [To: ][searchword >> autocomplete suggestion]
3 press <tab>

Actual Result (TB31)

a) focus moves away from the current recipient row immediately (regardless if autocompletion is finished or not, depending on typing speed and autocomplete response time, see Bug 1012397).
b) a new empty recipient row is created (this bug)
c) the just-added recipient row gets focus
It's important to note that this particular bug is exclusively about b), whether <tab> in this very narrow scenario should create a new recipient row or not.

Expected Result (as in TB24)

b) don't create a new empty recipient row (this bug)
c) As a consequence, as there's no other (empty or filled) row widget after the just-filled row widget, move focus to the next widget, which happens to be Subject box.

I think previous commenters have a good point saying for that specific scenario, <tab> should just get us to the next widget (subject box) without creating a new recipient line along the way, which if desired can be achieved with <enter>. That's efficient and arguably ux-consistent (depending on pov). So I'm sympathetic, perhaps even supportive of that idea. :)

I think both my comment 16 and comment 27 missed the distinction between two different scenarios:

Scenario 1 (regression, this bug)

Legitimate, but very narrow scenario: <tab> when autocompleting a new recipient in the last row which has recipient type set
-> move focus directly to subject field (without creating a new recipient row)

Scenario 2 (same behaviour as in TB24, no regression here)

using <tab> in any other recipient row (except those specified in scenario 1), regardless if involving autocompletion or not
-> moves focus along each and every recipient and corresponding recipient type selectors, including "empty" recipient rows IF they already have their recipient type selector set (so an existing semi-empty row like [To: ][ ] is always included in the <tab> sequence and it's not in the scope of this bug to change that.)

Magnus, can you reply to last paragraph of this comment?

(In reply to Richard Marti (:Paenglab) from comment #27)
> Magnus, I'm for the old behavior and you should ask for review.

That's fine with me.

> ENTER has to go to the next addressing field and TAB to the subject. It
> makes no sense to have two different keystrokes making the same. ENTER is
> like a CR saying "go to next line" which is fine. TAB says "go to the next
> widget" and the next widget is the subject field as the addressing widget
> with it's multiple lines is one widget.

Well, it'll be one widget when it will be one widget: after Bug 440377.
Current TB behaviour is different (correct/desirable or not): We have many places in UI where <tab> navigates elements below the perceived "widget level":
- message composition's header area (<tab> navigates all existing recipient and recipient type fields)
- message reader's header area (<tab> navigates all recipients and worse, two stops for each recipient as each star has its own useless stop; existing bug)
- message reader's body area (<tab> navigates all links found in body)

So the <tab> behaviour wrt this bug really depends on scenario, as explained in my comment 28.

@Magnus:
OT: That said, I like Richard's idea to think of the recipient area as a single widget with multiple lines, where <enter> creates a new line (similar to word processors).
In the same line of thought, what happened to <cursor up/down> keys in recipient area (when not autocompleting)? I recall they used to work in previous versions of TB, so that's looks like another regression, right? In TB31, it's now very hard and cumbersome to move around in the list of existing recipients using keyboard only, only <tab> and <shift+tab> are possible... Magnus, can you comment?

Speaking as someone, who has gotten used to hitting TAB twice, still thinking, that some consistency might be desirable, so below a try to find a semantic for the different key capabilities:

# TAB navigates the form as presented initially
# ENTER creates new fields (composer) or submits the form (web)

Of course all of the world is inconistent, yet day by day humans manage somehow and hitting one more key to compose an email message will not grind the economy to a halt ;) But at least a key should not have different meanings in a single widget, i.e. depending on whether auto-complete found the time and occasion to fire…

Comment on attachment 8463013
bug1043784_tab_adds_address_row.patch

Yeah, I think I'm convinced we should do this.
(This patch does not fix bug 1051564)

(In reply to Magnus Melin from comment #31)
> Comment on attachment 8463013
> bug1043784_tab_adds_address_row.patch
>
> Yeah, I think I'm convinced we should do this.

What does 'do this' mean?

Revert the behavior to what it has been for the last 10 years (hopefully)?

Thanks for working on it!

(In reply to Charles from comment #32)
>
> What does 'do this' mean?

Old behavior.

Comment on attachment 8463013
bug1043784_tab_adds_address_row.patch

Review of attachment 8463013:
-----------------------------------------------------------------

Looks good.

I must doing something wrong, but it fixes bug 1051564 for me.

It only fixes it partly, that is, when there's no match yet. Once you complete to a value you can't shift-tab back to the address type widget.

(In reply to Richard Marti (:Paenglab) from comment #33)
> (In reply to Charles from comment #32)
>>
>> What does 'do this' mean?

> Old behavior.

Excellent, thanks...

Sadly, this didn't make it into 31.1...

I am also all for fixing this bug sooner rather than later. It bits me every day and annoys me at least 20 times per day when it does. I am a long-time Thunderbird user, and this change really freaks me out. Sorry for being so blunt!

*** Bug 1073774 has been marked as a duplicate of this bug. ***

*** Bug 1075386 has been marked as a duplicate of this bug. ***

Comment on attachment 8463013
bug1043784_tab_adds_address_row.patch

Review of attachment 8463013:
-----------------------------------------------------------------

Patch looks good - thanks Magnus.

https://hg.mozilla.org/comm-central/rev/57ec66cb59ab -> FIXED

Comment on attachment 8463013
bug1043784_tab_adds_address_row.patch

[Approval Request Comment]
Regression caused by (bug #): bug 959209
User impact if declined: tab in autocomplete adds a new line, instead of just going to end of completion
Testing completed (on c-c, etc.): landed on trunk
Risk to taking this patch (and alternatives if risky): not risky

Comment on attachment 8463013
bug1043784_tab_adds_address_row.patch

[Triage Comment]
Should land on aurora & beta first.

https://hg.mozilla.org/releases/comm-aurora/rev/a22b167c6957
https://hg.mozilla.org/releases/comm-beta/rev/0c70f8c7a864

Any chance this can be backported to TB 32, so we don't have to wait forever for the fix... :)

(In reply to Charles from comment #45)
> Any chance this can be backported to TB 32, so we don't have to wait forever
> for the fix... :)

Hopefully you mean TB 31. And the intentions are extremely clear if you reexamine the flags and comments.

Yes, I meant 31, sorry, but...

Flags say 'None yet set'... am I missing something?

And I don't see any specific comment that actually says this will land in 31.x...

But if it will, then fine... thanks...

You must have missed comment 42 "Flags: approval-comm-esr31?", is the standard way to request landing on the release.

Oops, yeah, sorry about that...

But shouldn't that be reflected in the 'Flags' for the bug?

Although I do see it now also in the 'Attachments' section...

Oh well, I'll look more carefully next time...

Thanks again!

*** Bug 1098643 has been marked as a duplicate of this bug. ***

https://hg.mozilla.org/releases/comm-esr31/rev/ba2e66184ee5

We should probably back this out for ESR, since it makes bug 1107844 so much more exposed.

Ok, thanks Magnus, I've just backed it out: https://hg.mozilla.org/releases/comm-esr31/rev/3b6a364c4650

Since the fix to bug 1043310 (and therefore bug 1107844) has landed for ESR31, this fix should probably be put back in for ESR31, right, Magnus?

Magnus has the most context there.

It should be safe to re-land it now yes.

Please land for ESR31.
One question: Landing this on 35 (comment #43 and comment #44) means that we will see it in beta 36 one day soon now?

Magnus, my understanding is that you and I now have approval+ privileges in BMO. So you can make the call on approval-comm-esr31

Jorg: this already has status-thunderbird34:fixed and status-thunderbird35:fixed, and target milestone 36. It's long since this landed.

https://hg.mozilla.org/releases/comm-esr31/rev/fbb5a78e7140

*** Bug 1051564 has been marked as a duplicate of this bug. ***