1602372 - Trim recipient area keyboard focus ring (avoid unlimited recipient tab stops)

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, enhancement, P2)

Description

[Thomas D. (:thomas8)]

After bug 440377 (recipient pills grouped by recipient type), keyboard-navigating recipient area with tab key becomes a challenge with more recipients, which is easy to address with a reduced focus ring where the details are navigated with cursor keys.

STR

1. For new messages with 20+ To recipients (worse for 50+, 100+, you name it), try to add a CC-recipient using keyboard only.

Current result (2019-12-06)

• one tab stop on each To-recipient, need to tab 20+, 50+, or 100+ times to add CC-recipient using keyboard
• number of recipients = number of tabstops (potentially unlimited)
• prevents effective and predictable keyboard navigation

Expected result

• efficient focus ring keyboard navigation regardless of the number of recipients

Proposed solution

• only one tab stop per recipient field type (To, CC, BCC etc.)
• focus first recipient in the field (no initial selection pls for error-prevention; cf. Win Explorer)
• OR text cursor focus after the last recipient (ensure it's in view), makes adding recipients easy & show the focus on field border
• individual recipients can be efficiently and intuitively navigated with cursor keys (list-style), which will then focus and select each subsequent recipient (e.g. for easy copy/cut)

For comparison

• TB attachments list (one tab stop, then navigate many attachments with cursor keys)
• Win Explorer (one tab stop in files list, then cursor for unlimited files)
• FF bookmark dialog, tags list (one tab stop in the dialog, then cursor for unlimited tags)
• in general, unlimited lists of items are unfit for tab key navigation

Comment 1

[Alessandro Castellani [:aleca]]

For fields only navigation, we have the F6 shortcut.
Also, hitting END on a pill will move the focus immediately on the input field, right after the last pill.

I'm not super comfortable in hijacking the TAB key and I'd prefer to leave its native behaviour untouched.

Thoughts?

Comment 2

[Thomas D. (:thomas8)]

(In reply to Alessandro Castellani (:aleca) from comment #1)

For fields only navigation, we have the F6 shortcut.

Unfortunately not discoverable at all. That's "fast-track" focus ring, which deliberately stops only at a hand-picked selection of major UI elements, mostly panes. Plus historically, it's probably a workaround for that avoidable implementation problem of too many tab stops in recipient area, and a potentially unlimited number of tab stops on links in body, which we can't avoid.

Thoughts?

Here's one:

WAI-ARIA Authoring Practices 1.1

W3C Working Group Note 14 August 2019

§ 6.1 Fundamental Keyboard Navigation Conventions (1)

A primary keyboard navigation convention common across all platforms is that the tab and shift+tab keys move focus from one UI component to another while other keys, primarily the arrow keys, move focus inside of components that include multiple focusable elements. The path that the focus follows when pressing the tab key is known as the tab sequence or tab ring. [...]

The ARIA specification refers to a discrete UI component that contains multiple focusable elements as a composite widget. The process of controlling focus movement inside a composite is called managing focus. Following are some ARIA design patterns with example implementations that demonstrate focus management: [...]

Composite (abstract role) (2)

A widget that may contain navigable descendants or owned children.

Authors SHOULD ensure that a composite widget exists as a single navigation stop within the larger navigation system of the web page. Once the composite widget has focus, authors SHOULD provide a separate navigation mechanism for users to navigate to elements that are descendants or owned children of the composite element.

(1) https://www.w3.org/TR/wai-aria-practices/#kbd_generalnav
(2) https://www.w3.org/TR/wai-aria-1.1/#composite

Comment 3

[Richard Marti (:Paenglab)]

(In reply to Alessandro Castellani (:aleca) from comment #1)

For fields only navigation, we have the F6 shortcut.

F6 does not jump between To:, Cc:, Bcc: etc. it jumps directly from To: to Subject.

I'm not super comfortable in hijacking the TAB key and I'd prefer to leave its native behaviour untouched.

The tabbing through the pills is already faster than before because it needed two tab hits to go to the next address because the menulist was in-between a tab destination. On the other hand we could look as the recipient fields are normal text boxes and the pills are only a different representation of the text in them. Then using the cursor keys to navigate inside the fields is like moving the cursor in normal text, it moves only address wise.

Comment 4

[Thomas D. (:thomas8)]

Also note that having an unpredictable number of tab stops makes it much harder to develop efficient use patterns ("muscle memory").
If I have a message with 2 To-recipients and 100 CC recipients as a keyboard-only user, and I want to add a BCC-recipient, I'm not sure if
"tab, tab, tab, tab... ok, now in CC... tab, tab, tab, tab... oh, this doesn't work... let me use END... then TAB again for BCC"
is very memorable compared to
"Tab -> To. Tab-> CC. Tab -> BCC" (always).
Also depends where exactly we want to put the focus if we make each recipient field (To, CC, BCC) a single stop - first item focus (without selection) or cursor after last item. I think those Aria rules said first item somewhere. Then, pressing END when I really want to reach the END of that field makes more sense imo then just using END as a clumsy workaround to escape an indefinite tab sequence.

One aspect which I haven't fully considered is autocomplete. There's no problem to allow TAB to autocomplete the last item and remain with a concluding text cursor in the field component. It might be trickier if we allow tab for autocompletion to create pills between existing pills. But I think it would still feel OK if tab just autocompletes the current item and offers me a cursor insertion point after that item (or maybe exceptionally focuses only the next item as long as we don't have insertion points), but tab again gets me out to the next field (e.g. CC). In general, my impression is that tab is much less used for autocomplete than it was in the past. Check FF location bar - you can only auto-complete with Enter, tab navigates (micro-navigation in this case because we're in location bar edit mode).

Comment 5

[Thomas D. (:thomas8)]

(In reply to Richard Marti (:Paenglab) from comment #3)

(In reply to Alessandro Castellani (:aleca) from comment #1)

For fields only navigation, we have the F6 shortcut.

F6 does not jump between To:, Cc:, Bcc: etc. it jumps directly from To: to Subject.

Well, we could change that if needed, but it would still be undiscoverable.

I'm not super comfortable in hijacking the TAB key and I'd prefer to leave its native behaviour untouched.

Technical implementation of having 100 text boxes should not be prejudicial wrt logical, effective and accessible design of the tab focus ring. Nothing "native" here. Otherwise the current UI/behaviour "hijacks" tab as it gets lost in an indefinite number of minor stops.

The tabbing through the pills is already faster than before because it needed two tab hits to go to the next address because the menulist was in-between a tab destination.

Faster doesn't help much when the number of stops isn't known and all but unlimited. If I press tab for a little too long trying to get through my 100 recipients, I end up in body, where tab gets stuck. Tab should be a controlled and predictable movement through a mostly stable focus ring.

On the other hand we could look as the recipient fields are normal text boxes and the pills are only a different representation of the text in them. Then using the cursor keys to navigate inside the fields is like moving the cursor in normal text, it moves only address wise.

Absolutely. As I explained on the other bug, it's now a mix of item list and text box UI, but the text input connotations are certainly still strong.

Comment 6

[Alessandro Castellani [:aleca]]

You guys raise good points, and indeed the inconsistent amount of TABs necessary to switch between recipients rows is not great.

So, here's a potential plan:

• Add the other visible recipients to the F6 cycles.
• TAB focuses on the recipient input field, not single pills. Pills are accessible with the arrow keys.
• If the Recipient labels remain above the subject field (TBD on bug 1601748), focus the entire row once and not every single labels, allowing navigation with the arrow keys.

Does this sound good?

Comment 7

[Richard Marti (:Paenglab)]

Yes, sounds good.

Comment 8

[Thomas D. (:thomas8)]

(In reply to Alessandro Castellani (:aleca) from comment #6)

So, here's a potential plan:

• Add the other visible recipients to the F6 cycles.

Yes, one fast-track F6 stop each on To, CC, BCC fields could be useful.

• TAB focuses on the recipient input field, not single pills. Pills are accessible with the arrow keys.

Great, that makes the recipient area tab-navigable again. If we're not happy with cursor in the input field (vs. focusing the first item), we can still play with that.

• If the Recipient labels remain above the subject field (TBD on bug 1601748), focus the entire row once and not every single labels, allowing navigation with the arrow keys.

Interesting. Let's try that and see how it feels. So the logic is that it's one stop for adding other recipient types, then you select the flavor with cursor keys (almost like a radio group, and reminiscent of the traditional UI patterns). Speeds up the simple case of not adding BCC; otoh makes adding BCC a bit clumsier (but still way easier than in the old interface). It's a bit surprising because normally buttons have their own tab stop.

Does this sound good?

Yes. Thank you! :-)

Comment 9

[Alessandro Castellani [:aleca]]

Attachment: 1602372-pills-tab-focus.patch

Forces the focus to the proper input field or element when a Tab or Shift+Tab even is triggered on the pill.

Comment 10

[Magnus Melin [:mkmelin]]

Comment on attachment 9119614 [details] [diff] [review]
1602372-pills-tab-focus.patch

Review of attachment 9119614 [details] [diff] [review]:
-----------------------------------------------------------------

F6 doesn't stop at Cc

::: mail/base/content/mailWidgets.js
@@ +2238,5 @@
> +          if (event.shiftKey) {
> +            this.moveFocusToPreviousElement(pill);
> +            return;
> +          }
> +          pill.originalInput.focus();

Not sure if this is the focus that's supposed to be shifted. Maybe the selected pill, or both? Visually I can't which pill is focussed and what I'm to do with that focus. When something in the middle of the row has focus typing something in doesn't work, which feels a bit buggy. Maybe typing needs to move you to the end automatically

Comment 11

[Thomas D. (:thomas8)]

Much better behaviour now. Can we polish this a bit?
I constantly feel that maybe I pressed Tab for too long or TB is snatching my focus because for a split second before moving focus to where it's supposed to be, current patch often focuses an unrelated pill on the way. So things become a bit flickery. Some of these cases could be cured by listening to key-up instead of key-down maybe. Other cases may need other solutions.

Comment 12

[Thomas D. (:thomas8)]

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

So things become a bit flickery. Some of these cases could be cured by listening to key-up instead of key-down maybe.

In fact, e.g. with cursor on originalInput, if I press Shift+Tab a bit quickly (seesaw style), it even fails: Focus flashes to the last pill for a split second, and then returns to originalInput (instead of going to previous element).

Comment 13

[Alessandro Castellani [:aleca]]

Attachment: 1602372-pills-tab-focus.patch

All right, this was more complex than I expected.
Please ignore the F6 for now as I will take care of that in a follow up patch in the bug.

For now, focus on the navigation via Tab and Shift+Tab.
The patch handles the focus in order to completely skip the pills and cycle through these elements:

• Input fields
• Close labels
• Recipient labels

Let me know if I miss something.

Comment 14

[Thomas D. (:thomas8)]

Comment on attachment 9119970 [details] [diff] [review]
1602372-pills-tab-focus.patch

Review of attachment 9119970 [details] [diff] [review]:
-----------------------------------------------------------------

Better, thanks! From my reading of the code (haven't tested yet), we still have some flaws.

::: mail/base/content/mailWidgets.js
@@ +2068,5 @@
> +        .getElementById("extraRecipientsLabel")
> +        .addEventListener("keypress", event => {
> +          if (event.key == "Tab" && !event.shiftKey) {
> +            event.preventDefault();
> +            document.getElementById("toAddrInput").focus();

Somewhere Magnus requested that To should be hidden for newsgroup scenarios -  if that's applicable, To field may not always exist.

@@ +2088,5 @@
> +      event.preventDefault();
> +
> +      // If the Shift+Tab event happened in the 'To' input field
> +      if (input.id == "toAddrInput") {
> +        document.getElementById("extraRecipientsLabel").focus();

This will fail when all extra recipients have been set, so the extraRecipientsLabel is gone.

@@ +2488,5 @@
> +     * @param {XULElement} pill - The mail-address-pill element.
> +     */
> +    moveFocusToPreviousElement(pill) {
> +      if (pill.originalInput.id == "toAddrInput") {
> +        document.getElementById("extraRecipientsLabel").focus();

Dito: extraRecipientsLabel may not be available.

::: mail/components/compose/content/addressingWidgetOverlay.js
@@ +694,5 @@
> + */
> +function closeLabelKeyPress(event, element, labelID) {
> +  switch (event.key) {
> +    case "Enter":
> +      hideAddressRow(element, labelID);

I think you are still losing keyboard focus after removing rows. We have to figure out the nearest focusable thing going forward and focus that.

Comment 15

[Magnus Melin [:mkmelin]]

Thomas, the elements are not "gone", just hidden, so getElementById would still work.

Comment 16

[Magnus Melin [:mkmelin]]

Comment on attachment 9119970 [details] [diff] [review]
1602372-pills-tab-focus.patch

Review of attachment 9119970 [details] [diff] [review]:
-----------------------------------------------------------------

This looks ok to me.

I notice this (also on trunk). If I have both To and Newsgroup showing, selecting autocompleted pills in To will always move the cursor to the end of Newsgroup, instead of staying at the end of To. Do we have a bug for that?

Comment 17

[Thomas D. (:thomas8)]

(In reply to Magnus Melin [:mkmelin] from comment #15)

Thomas, the elements are not "gone", just hidden, so getElementById would still work.

Magnus, for the purposes of keyboard-focus (the topic of this bug, and the line of code on which I commented), the elements are hidden = unavailable = gone, so .focus() on a hidden element may or may not cause an error technically, but it's ineffective. From what I know, focusing hidden elements results in loss of visible keyboard-focus for the user, which is a bug in terms of UX.

Comment 18

[Thomas D. (:thomas8)]

(In reply to Magnus Melin [:mkmelin] from comment #16)

I notice this (also on trunk). If I have both To and Newsgroup showing,
selecting autocompleted pills in To will always move the cursor to the end

Is it selecting an existing pill or creating/confirming a new pill with ENTER? Using autocomplete doesn't seem relevant for that problem.

of Newsgroup, instead of staying at the end of To. Do we have a bug for that?

Yes, I filed bug 1603166 one month ago when Alessandro was requesting to file bugs against the prototype.

Comment 19

[Thomas D. (:thomas8)]

(In reply to Magnus Melin [:mkmelin] from comment #16)

Review of attachment 9119970 [details] [diff] [review]:

This looks ok to me.

So my patch review (comment 14) identified 4 instances where the current patch may cause loss of keyboard focus (also after removing rows), so does your subsequent review+ (comment 16) indicate that this is acceptable?

Comment 20

[Magnus Melin [:mkmelin]]

Comment on attachment 9119970 [details] [diff] [review]
1602372-pills-tab-focus.patch

Review of attachment 9119970 [details] [diff] [review]:
-----------------------------------------------------------------

Ah you're right, that could be a problem. 
Maybe better to find closest right type element instead of focusing on specific ids

Comment 21

[Alessandro Castellani [:aleca]]

Thank you both for the detailed reviews.
I'm reworking this to fix those issues. As I said, it's more complicated than I expected.
Bare with me :D

Comment 22

[Alessandro Castellani [:aleca]]

Attachment: 1602372-pills-tab-focus.patch

All right, this was a wild ride.
I think I was able to cover all the possible scenarios and account for any hidden or collapsed element.
I fixed also the focus change when hiding a row or when the selection is on a pill and the Tab key is pressed.
Let me know if you find something missing or glitchy.
I'll take care of the F6 in a follow up patch.

Comment 23

[Magnus Melin [:mkmelin]]

Comment on attachment 9120917 [details] [diff] [review]
1602372-pills-tab-focus.patch

Review of attachment 9120917 [details] [diff] [review]:
-----------------------------------------------------------------

If I have To, Cc, Bcc showing, F6 doesn't stop at Cc nor Bcc. (And would assume, any other further extra fields)

::: mail/base/content/mailWidgets.js
@@ +2073,5 @@
> +        .addEventListener("keypress", event => {
> +          if (event.key == "Tab" && !event.shiftKey) {
> +            event.preventDefault();
> +            let row = document
> +              .getElementById("recipientsContainer")

this widget should not be referencing specific ids it doesn't control

@@ +2078,5 @@
> +              .querySelector(".address-row:not(.hidden)");
> +            // If the close label is not available, focus on the input field.
> +            if (!row.querySelector(".aw-firstColBox > label")) {
> +              row
> +                .querySelector(`input[is="autocomplete-input"][recipienttype]`)

are there others, that do not have [recipienttype] ?

Comment 24

[Alessandro Castellani [:aleca]]

If I have To, Cc, Bcc showing, F6 doesn't stop at Cc nor Bcc. (And would assume, any other further extra fields)

Yeah, as I said before I didn't include the F6 fixes in this patch as I wanted to do it in a follow-up patch after the Tab issue was solved.
I'll do everything in one patch.

are there others, that do not have [recipienttype] ?

Yes, every pill has an autocomplete-input inside, the recipienttype attribute is only used in the main address row.

Comment 25

[Magnus Melin [:mkmelin]]

Ah yeah sorry, I did read that, just forgot about it!

Comment 26

[Thomas D. (:thomas8)]

Comment on attachment 9120917 [details] [diff] [review]
1602372-pills-tab-focus.patch

-

Comment 27

[Thomas D. (:thomas8)]

--

Comment 28

[Alessandro Castellani [:aleca]]

Attachment: 1602372-pills-tab-focus.patch

Patch updated.

I didn't include the F6 edits as I wanted to double check with you how to handle it.
Currently in 68, the F6 only cycles through specifically selected areas and field with IDs, ignoring all the address rows previously written.
How do we want to update this?
Do we want it to cycle through all the available input fields? Does it make sense doing so since the TAB keypress has been tweaked to behave in that way?

Maybe the F6 should cycle only through currently visible address row fields.

Comment 29

[Alessandro Castellani [:aleca]]

Attachment: 1602372-pills-tab-focus-PART2.patch

This is the follow up patch dealing with the F6 focus.
I'm cycling and forcing the focus through all the available fields in the recipients area.

Comment 30

[Magnus Melin [:mkmelin]]

Comment on attachment 9121878 [details] [diff] [review]
1602372-pills-tab-focus.patch

Review of attachment 9121878 [details] [diff] [review]:
-----------------------------------------------------------------

Severely bitrotted so can't test. Some nits below.

::: mail/base/content/mailWidgets.js
@@ +2067,4 @@
>        }
> +
> +      // Force the focus on the first available input field if Tab is
> +      // pressed on the  extraRecipientsLabel label.

nit: double space

@@ +2484,5 @@
> +        row.querySelector(".aw-firstColBox > label").focus();
> +        return;
> +      }
> +
> +      // If a previous address row is abailable and not hidden,

typo

@@ +2486,5 @@
> +      }
> +
> +      // If a previous address row is abailable and not hidden,
> +      // focus on the autocomplete input field.
> +      let previous_row = row.previousElementSibling;

no snake_namings please

::: mail/components/compose/content/MsgComposeCommands.js
@@ +6495,5 @@
> +  if (event.key != "Tab" || event.shiftKey) {
> +    return;
> +  }
> +
> +  // if extra labels are available, let the focus move normally.

If

::: mail/components/compose/content/addressingWidgetOverlay.js
@@ +700,5 @@
> +/**
> + * Handle the keypress event on the close label of a recipient row.
> + *
> + * @param {Event} event - The DOM Event.
> + * @param {XULelement} element - The focused label.

{Element}

Comment 31

[Magnus Melin [:mkmelin]]

Comment on attachment 9121893 [details] [diff] [review]
1602372-pills-tab-focus-PART2.patch

Review of attachment 9121893 [details] [diff] [review]:
-----------------------------------------------------------------

This patch applied, but not sure if it needs the earlier or not. Using F6 i get stuck in the identity selector (Shift F6 will get me away though).

Comment 32

[Alessandro Castellani [:aleca]]

Thanks for the comments, I'm updating the patches to work with the latest changes.

This patch applied, but not sure if it needs the earlier or not. Using F6 i get stuck in the identity selector (Shift F6 will get me away though).

Yes, the second patch won't work without the first.

Comment 33

[Alessandro Castellani [:aleca]]

Attachment: 1602372-pills-tab-focus.patch

Comment 34

[Alessandro Castellani [:aleca]]

Attachment: 1602372-pills-tab-focus-PART2.patch

Comment 35

[Magnus Melin [:mkmelin]]

Comment on attachment 9122947 [details] [diff] [review]
1602372-pills-tab-focus.patch

Review of attachment 9122947 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good! r=mkmelin

Comment 36

[Alessandro Castellani [:aleca]]

This can't land until bug 1603166 lands as some unbitrotting will be necessary.

Comment 37

[Alessandro Castellani [:aleca]]

Attachment: 1602372-pills-tab-focus.patch

Unbitrotted.

Comment 38

[Alessandro Castellani [:aleca]]

Attachment: 1602372-pills-tab-focus-PART2.patch

Unbitrotted and try-run launched: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=59dc7babb43b80a6ceb0ce2f45a3dc0ca3b5465b

Comment 39

[Alessandro Castellani [:aleca]]

Oopsie, lot's of test failures.
Taking care of those.

Comment 40

[Alessandro Castellani [:aleca]]

Attachment: 1602372-pills-tab-focus-PART2.patch

Tests fixed and new try-run launched: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=d53067f0498e76c8cdf4629245bd4930109cb7c4

Comment 41

[Alessandro Castellani [:aleca]]

Fixed on Linux but failing on macos, darn.
I'll fix that and then I'll run another test including the Windows build, as I suspect the different keyboard layout might affect the behaviour of how we manage focus rings.

Meanwhile, I'm pinging Richard.
Would you be able to load these 2 patches and run ./mach mochitest mail/test/browser/composition/browser_focus.js?
Also, if you could confirm the focus ring moves properly around the items in the compose window when using CTRL and F6.

Comment 42

[Richard Marti (:Paenglab)]

I don't build with tests, so can't run tests. I tried your patches and F6 and TAB works but not CTRL. Maybe you meant SHIFT instead, because this works together with F6 and TAB. Inside the recipient fields I can use the left/right arrow keys

Maybe something for a new bug because it's with and without your patch: The extraRecipientsPanel doesn't support any keyboard navigation. Opening with RETURN works but then nothing more, I need the mouse.

Comment 43

[Alessandro Castellani [:aleca]]

Yes, sorry, I meant TAB and F6, and SHIFT to reverse the order.
I'm able to cycle through the items in the extraRecipientsPanel with the TAB key. Doesn't work on Windows?

Comment 44

[Richard Marti (:Paenglab)]

Ah yes, TAB works in the extraRecipientsPanel but I see no feedback which one has the focus. Tried also on Linux. That's why I thought it doesn't work. Tabbing in this panel is also a bit weird, using the arrow keys would be more logical (the FX AppMenu uses also the arrow keys).

Comment 45

[Alessandro Castellani [:aleca]]

Ok, thanks for the feedback. I'll take care of that in a dedicated bug.

Comment 46

[Alessandro Castellani [:aleca]]

Attachment: 1602372-pills-tab-focus-PART2.patch

Apparently macos overrides the default accessibility.tabfocus to limit the focusable items only to input fields.
Where Windows and Linux come with a default value of 7 (allow focus on all elements), macOS comes with a default value of 2.

More info here: https://developer.mozilla.org/en-US/docs/Mozilla/Preferences/Preference_reference/accessibility.tabfocus

Adding a custom prefs fixed the focusing issue.
I'm asking an extra feedback to be sure this addition is correct.
Here's another try-run: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=6974472b1439ee45b83b14fc23ca466ee641b9bd

Comment 47

[Alessandro Castellani [:aleca]]

Pinging Richard to see if adding

#ifdef XP_MACOSX
pref("accessibility.tabfocus", 7);
#endif

causes any accessibility issues on macos when tabbing through focusable items.

Comment 48

[Richard Marti (:Paenglab)]

I don't think we should override the system behaviour. For the test it seems okay to enable it but for the user it should be consistent system wide.

I have changed this globally in the system prefs to stop on every element and not only text fields.

Comment 49

[Alessandro Castellani [:aleca]]

That's a good point. How do I enable this only for tests?

Comment 50

[Richard Marti (:Paenglab)]

I know too little about the tests but in the test initialization it should be doable to enable this pref during the tests. I'm sure Geoff knows where to set this.

Comment 51

[Magnus Melin [:mkmelin]]

You just set the pref, and unset it during cleanup. Like https://searchfox.org/comm-central/rev/91a3a1514045b75e4d6cf3c9d8236ba75d8716b9/mail/test/browser/cloudfile/browser_attachmentUrls.js#106

Comment 52

[Alessandro Castellani [:aleca]]

Attachment: 1602372-pills-tab-focus.patch

Unbitrotted patch.

Comment 53

[Alessandro Castellani [:aleca]]

Attachment: 1602372-pills-tab-focus-PART2.patch

Preferences fixed for tests.
Try-run to confirm: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=7cd403e8ca0bf674f9d4a96342224904e413a24a

Comment 54

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/fefcbe1ff081
Move focus ring through compose input fields on Tab keypress. r=mkmelin
https://hg.mozilla.org/comm-central/rev/91f77a3708ff
Move focus ring through compose input fields on F6 keypress. r=mkmelin