STR:

• Select a folder in the folder tree
• Open the calendar tab
• Press up or down

The selected folder in the folder tree changes. You can see this straight away because the title of the 3-pane tab changes.

I'm working on a patch but I'm not sure that what I'm proposing is the right thing to do.

Comment on attachment 9205598 [details]
Bug 1695098 - When switching tabs, focus the most recently active element. r?aleca

Does this feel good to you? Sure it's better than nothing, but is it right?

Comment on attachment 9205598 [details]
Bug 1695098 - When switching tabs, focus the most recently active element. r?aleca

Great find here!
This is an accessibility nightmare and I'm ashamed that I never noticed it.

Yes, I think this is a good initial step to guarantee consistent focus.

One thing that we should definitely implement here is setting the focus on the first focusable item inside a newly opened Tab.
E.g.: When the user opens the calendar for the first time, the focus should be moved on the first available calendar slot (or maybe the calendar list?).

• Happens all the time, and we've seen and bandaid-fixed this before, e.g. in my bug 1666885.
• We probably have the same problem in a lot more places, only it's very hard to notice.
• It's much worse than described because that wrong focus in the three-pane folder list is actually actionable - pressing DEL from Calendar tab will start deleting folders in 3-pane, and I just got a compact folders message in calendar tab. Interestingly, message pane is not affected, as I noted in Bug 1666885 Comment 8 - but we should keep an eye on the single-letter shortcuts anyway!
• We'll keep running into this as long as the whole main window is a single thing instead of technically separate tabs with their own context.
  Maybe one day we should fix that big design problem. Magnus will know the technical details.

(In reply to Geoff Lankow (:darktrojan) from comment #2)

Comment on attachment 9205598 [details]
Bug 1695098 - Shift focus on tab switch. r?aleca
Does this feel good to you? Sure it's better than nothing, but is it right?

Thank you for tackling this, Geoff, you rock! From reading the code, this should feel quite awesome (remember focus of the old tab and restore that when you come back to it), and is very much in line with popular bug 487386 - tabs should maintain exactly what they had when you return to them.

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

One thing that we should definitely implement here is setting the focus on the first focusable item inside a newly opened Tab.
E.g.: When the user opens the calendar for the first time, the focus should be moved on the first available calendar slot (or maybe the calendar list?).

I think that's a case to case decision to take - initial tab focus should be as useful as possible (and yeah, somewhere to the top). A good example is Options tab where we implemented initial focus on the Search box (which also happens to be the topmost item, but one could argue that the first element would be the General category element on the left). Maybe search boxes are pretty good candidates for initial focus if present.

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

One thing that we should definitely implement here is setting the focus on the first focusable item inside a newly opened Tab.
E.g.: When the user opens the calendar for the first time, the focus should be moved on the first available calendar slot (or maybe the calendar list?).

I haven't really implemented this here, in part because I'm already several layers of distraction deep, and in part because it's complicated. I'll file a follow-up.

Oh, I also meant to say: if there's nothing already focussed in a tab when switching to it, the focus returns to the window itself. Press tab once from there and the focus is on the tab element itself, press again and it's at the first focusable descendant of the tab content. I think that's a reasonable compromise for now.

Looks like I've broken mail/test/browser/global-search-bar/browser_globalSearchBar.js, but that test doesn't make a lot of sense to me anyway. I'll investigate further.

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/e9909e0d9bc3
When switching tabs, focus the most recently active element. r=aleca

Pushed with a fix for browser_globalSearchBar.js.

Comment on attachment 9205598 [details]
Bug 1695098 - When switching tabs, focus the most recently active element. r?aleca

[Approval Request Comment]
Regression caused by (bug #): I think it's always been this way
User impact if declined: Focus remains on elements that aren't visible and bad things can happen if some keyboard shortcuts are used
Testing completed (on c-c, etc.): Landed 11 days ago
Risk to taking this patch (and alternatives if risky): I don't think this is risky, there is a change in behaviour but it's a good change

Comment on attachment 9205598 [details]
Bug 1695098 - When switching tabs, focus the most recently active element. r?aleca

[Triage Comment]
Approved for beta

Thunderbird 87.0b3:
https://hg.mozilla.org/releases/comm-beta/rev/170df637ae15

Comment on attachment 9205598 [details]
Bug 1695098 - When switching tabs, focus the most recently active element. r?aleca

[Triage Comment]
Approved for esr78

Thunderbird 78.9.0:
https://hg.mozilla.org/releases/comm-esr78/rev/d4aeebfe6294

Test fixed for 78:
https://hg.mozilla.org/releases/comm-esr78/rev/51fc203b8ac0