1761455 - Focus stealing inconsistent when switching between spaces

Status: NEW

(Thunderbird :: Mail Window Front End, defect)

Description

[Henry Wilkes (they/them) [:henry-x]]

Sometimes activating a spaces button will steal focus away from the spaces toolbar, and sometimes it won't:

• Activating the mail, calendar and task buttons never seems to steal focus.
• Activating the addressbook button moves the focus to the addressbook search bar the first time it is opened. But it doesn't steal the focus when subsequently switched to.
• Activating the chat button always moves the focus.

We should try and make the behaviour consistent. Either we never move focus or we always move focus. On the one hand, activating a button is a request to go to that space, so moving focus might be expected. However, we should take into account that it can be disorientating if it drops you into the middle of the document.

We should also consider whether we can save and restore focus when leaving and returning to a space. Especially if you leave the space via keyboard shortcuts. E.g. you're editing a contact, switch to the mail tab to read a detail, and then switch back to edit the contact.

Comment 1

[Alessandro Castellani [:aleca]]

Thanks for opening this bug.
IIRC, there are some duplicates or adjacent bugs around related to the focus not being remembered when switching tabs, as well as a very old one where the focus is all over the place when starting TB.

Adding other folks to this bug to see if we can collect and organize all those similar bugs and define a plan of action.

Comment 2

[WaltS48 [:walts48]]

Where does activating the Chat button put the focus in the Chat tab?

I am not seeing that with the recent 100.0a1 on Fedora 35 Workstation.

I do see the cursor in the Search bar of the address book, and it stays there if I don't search, then activate another button, then go back to the address book.

Can't reproduce using 99.0b2 on Fedora.

Comment 3

[Henry Wilkes (they/them) [:henry-x]]

(In reply to WaltS48 [:walts48] from comment #2)

Where does activating the Chat button put the focus in the Chat tab?

Either the contact list or a button to create an account or a button to open the account manager, depending on if you have an (online) account or not https://searchfox.org/comm-central/rev/e8c18e9b507f8fe0db25ca5d9ce63b5ce9014663/mail/components/im/content/chat-messenger.js#1309

I am not seeing that with the recent 100.0a1 on Fedora 35 Workstation.

The easiest way to see is to navigate to the spaces toolbar with tab and activating the chat space with Space or Enter. You should notice that the focus ring leaves the chat button. Note that the chat tab doesn't show the focus on the contact list very clearly.

Comment 4

[WaltS48 [:walts48]]

Thanks!

I can't seem to reproduce the chat issue on Fedora Linux or Windows 10 with my 100.0a1 Build ID 20220328095214.

Comment 5

[Henry Wilkes (they/them) [:henry-x]]

(In reply to Henry Wilkes [:henry] from comment #0)

We should also consider whether we can save and restore focus when leaving and returning to a space. Especially if you leave the space via keyboard shortcuts. E.g. you're editing a contact, switch to the mail tab to read a detail, and then switch back to edit the contact.

Note: tabmail already saves the lastActiveElement https://searchfox.org/comm-central/rev/91923108c54cd5e574fbaeed2b6af0cbeee37d37/mail/base/content/tabmail.js#1658 so we can automatically use that when switching tabs directly, but this doesn't work if the focus is outside the tab: e.g. if you move into the spaces toolbar via keyboard this will change the document.activeElement and so the current tab will not have a lastActiveElement.

For tabs that are just a xul:browser, such as the new addressbook, the lastActiveElement just points to the browser: the browser itself remembers its activeElement by default, so we can just focus the browser to focus that tab's last focused element. However, for the non-browser tabs share the same document as the toplevel, so it is much easier for them to loose track of their activeElement. What we could do is put a blur listener on each tab panel, and set the lastActiveElement there instead.