1730153 - All composition dialogs do no longer show keyboard focus on any buttons

Status: RESOLVED FIXED

(Thunderbird :: Theme, defect, P1)

Description

[Thomas D. (:thomas8)]

Seen on 91.1.0 (64-bit) and 94.0a1 (2021-09-08) (64-bit).
Richard, any insights?

STR

1. Compose and open any dialog (seems that all dialogs have a default button).

• e.g. Insert > Image...

2. Press Tab to the nearest button which is not the default button

• e.g. press Tab once to focus Choose file... button

3. Try to identify where your keyboard focus currently is.
4. For advanced guessing level, repeat steps 1 - 3 on Edit > Find and Replace... dialog after entering a search word.

Actual

• impossible to keep track of focus because it is not indicated on any focused buttons (no focus ring, except that default button wrongly has blue border indication always as if it had focus, even when it has not).

Expected

• When pressing Tab, whichever element has focus must have a clear focus indication (typically blue focus ring)

Side note: Default button visual behaviour is also useless, but I guess that's for another bug.

Comment 1

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

This seems to be because --focus-outline-color used for focus-visible (aka -moz-focusring https://searchfox.org/comm-central/rev/15a241fd84b92b74caf0b75d70ffed980b3397d1/mail/themes/shared/mail/themeableDialog.css#229) is not set.

It is defined in messenger.css (https://searchfox.org/comm-central/rev/15a241fd84b92b74caf0b75d70ffed980b3397d1/mail/themes/shared/mail/messenger.css#46), but this doesn't seem to be in scope for a lot of dialogs.

Note, this used to use -moz-accent-color as a fallback (https://searchfox.org/comm-central/diff/b9dc073da60b4072110936b499dd6ceef80ee748/mail/themes/shared/mail/themeableDialog.css#227), which is in scope.

It seems like we generally rely on messenger.css being in scope for a lot of styling. I wonder if it is time to split out the common stuff (like common tagName/class based styling, and variables) and putting it in a css that every window uses. The common stuff seems to be currently split between themeableDialog.css and messenger.css.

Comment 2

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

Note that --focus-outline-offset is similarly used for the same ruleset, but is only defined in messenger.css. Which means it uses the fallback -1px rather than the messenger.css --focus-outline-offset value of 1px.

Comment 3

[Thomas D. (:thomas8)]

Great analysis, thanks Henry. Can you take this?

Comment 4

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

What do you think about @import url("chrome://messenger/skin/messenger.css"); at the top of themableDialog.css. Do you know of any reasons not to do this?

Comment 5

[Richard Marti (:Paenglab)]

This would be dangerous as we have a lot of windows/dialogs that already import messenger.css and then all matching rules will be applied twice.

And I have already a patch that works without importing messenger.css and additionally changes the [default] buttons from showing an outline to giving them a blue background.

So taking the bug.

Comment 6

[Richard Marti (:Paenglab)]

And additionally we're planning to move all variables from messenger.css to a new variables.css to make the imports smaller when only the variables are needed.

Comment 7

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

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

This would be dangerous as we have a lot of windows/dialogs that already import messenger.css and then all matching rules will be applied twice.

I was also going to remove the unnecessary messager.css inclutions from the xhtmls.

And I have already a patch that works without importing messenger.css and additionally changes the [default] buttons from showing an outline to giving them a blue background.

Can you share the bug id for this change, or is it not yet created?

So taking the bug.

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

And additionally we're planning to move all variables from messenger.css to a new variables.css to make the imports smaller when only the variables are needed.

Sounds good! :) Can you CC me when you make the bug?

Comment 8

[Richard Marti (:Paenglab)]

Attachment: 1730153-button-focus.patch

Instead of using --focus-outline-color use --highlight-color which is defined inside themeableDialog.css.

Additionally I changed the button[default] code to make the button background like the primary buttons instead of the outline.

With this changes in commonDialog.xhtml the messenger.css import is obsolete.

Comment 9

[Thomas D. (:thomas8)]

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

This would be dangerous as we have a lot of windows/dialogs that already import messenger.css and then all matching rules will be applied twice.

And I have already a patch that works without importing messenger.css and additionally changes the [default] buttons from showing an outline to giving them a blue background.

Are you also fixing this problem (another regression in this area):
When focus is moved to a button different from the default button, the default button must no longer show up as a default button, but just as a regular button?

Comment 10

[Richard Marti (:Paenglab)]

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

Are you also fixing this problem (another regression in this area):
When focus is moved to a button different from the default button, the default button must no longer show up as a default button, but just as a regular button?

No, because this leads to a blinking button. But if Alex wants this I can do it easily by changing [default] to [default="true"].

Comment 11

[Richard Marti (:Paenglab)]

Attachment: 1730153-button-focus.patch

Small change to not give hover feedback on disabled button.

Comment 12

[Alessandro Castellani [:aleca]]

When focus is moved to a button different from the default button, the default button must no longer show up as a default button, but just as a regular button?

No, this is not a good UX approach unfortunately.
"Default" buttons should remain with the same color style and the focus shouldn't affect that state as "focus" and "default" style are and should be two completely different things.
The change of focus is only representative of the current target of the action (enter, spacebar), and it shouldn't visually change the default action of the entire dialog.

Comment 13

[Alessandro Castellani [:aleca]]

Are we sure this was regressed by bug 1710619?
When that bug landed all the dialogs had proper focus.

Comment 14

[Alessandro Castellani [:aleca]]

Comment on attachment 9240576 [details] [diff] [review]
1730153-button-focus.patch

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

Looks good, thanks.

Comment 15

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

(In reply to Alessandro Castellani [:aleca] from comment #13)

Are we sure this was regressed by bug 1710619?
When that bug landed all the dialogs had proper focus.

This is the bug that removed the -moz-accent-color fall back. Looking at the files during the revision, the --focus-outline-color definition would similarly be missing without messenger.css. However, the change was protected by -moz-proton https://hg.mozilla.org/comm-central/diff/d401469fde9df23baba053e0769a1327b5ffa3e9/mail/themes/shared/mail/themeableDialog.css#l1.12 I'm not sure what to make of that.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/98ce4cf9faff
Use "--highlight-color" for focused buttons and change the button[default] appearance. r=aleca

Comment 17

[Richard Marti (:Paenglab)]

Attachment: 1730153-button-focus-beta-ESR.patch

Needs to applied after bug 1728712

[Approval Request Comment]
User impact if declined: no visible focus on buttons in dialogs
Testing completed (on c-c, etc.): on c-c
Risk to taking this patch (and alternatives if risky): should be low

Comment 18

[Wayne Mery (:wsmwk)]

Comment on attachment 9240726 [details] [diff] [review]
1730153-button-focus-beta-ESR.patch

[Triage Comment]
approved for beta

Rob, note "Needs to applied after bug 1728712"

Comment 19

[Rob Lemley [:rjl]]

Thunderbird 93.0b2:
https://hg.mozilla.org/releases/comm-beta/rev/56d471f1066f

Comment 20

[Wayne Mery (:wsmwk)]

Comment on attachment 9240726 [details] [diff] [review]
1730153-button-focus-beta-ESR.patch

[Triage Comment]
Approved for esr91

Comment 21

[Rob Lemley [:rjl]]

Thunderbird 91.1.1:
https://hg.mozilla.org/releases/comm-esr91/rev/d0a698abd74b

Comment 22

[Zoe Martin]

Attachment: 2021-09-15 23_07_05-Window.png

This doesn't look right, you should back this out from the ESR.

Comment 23

[Alessandro Castellani [:aleca]]

The only problem I see is the color contrast of the primary button, which is strange because it looks correct on trunk on macOS and Linux.
This doesn't need a full backout but a follow up to fix it.
Richard, can you take a look?

Comment 24

[Rob Lemley [:rjl]]

The ESR patch contained an error: --primary-text-color: SelectedItemText; should be --primary-text-color: HighlightText;. SelectedItemText isn't implemented in 91.

Build 2 will run on Thursday with the fix.

Comment 25

[Richard Marti (:Paenglab)]

Like Rob wrote in comment 24.

Comment 26

[Rob Lemley [:rjl]]

Attachment: 1730153-button-focus-ESR_fixed.patch

This is the version for esr91 with SelectedItemText replaced with HighlightText.

Comment 27

[Rob Lemley [:rjl]]

Comment on attachment 9241581 [details]
1730153-button-focus-ESR_fixed.patch

[Triage Comment]
Previously approved

Comment 28

[Rob Lemley [:rjl]]

Thunderbird 91.1.1 Backout (comment 21):
https://hg.mozilla.org/releases/comm-esr91/rev/1e5d5f8a0d42

Comment 29

[Rob Lemley [:rjl]]

Thunderbird 91.1.1:
https://hg.mozilla.org/releases/comm-esr91/rev/ff307e08b121

Comment 30

[Zoe Martin]

Attachment: 2021-09-16 18_55_35-Window.png

Can you please explain the UI here. Blue button with blue focus ring on other button (after hitting tab)? Seems very confusing. What will pressing enter do in that situation?

Comment 31

[Alessandro Castellani [:aleca]]

Blue buttons: Primary/Default buttons of a dialog. This is a standard and recommended UX paradigm to show what's the default action of the dialog.
Blue focus ring: To indicate the currently focus element, which is the element that will get the enter/space keyboard event.

It's pretty standard stuff. It looks confusing because TB never did it, which is very wrong.
Subdialogs and other similar elements inherited from m-c do exactly the same.

Comment 32

[Thomas D. (:thomas8)]

(In reply to Alessandro Castellani [:aleca] from comment #31)

It's pretty standard stuff. It looks confusing because TB never did it, which is very wrong.

Really? I don't think so. Both Firefox and Thunderbird are now doing this in a weird way, and seemingly deviating from long-standing UX paradigms still seen elsewhere (e.g. in any application that ships with Windows 10, Search and Replace dialog in Notepad and WordPad is a good example).

Blue buttons: Primary/Default buttons of a dialog. This is a standard and recommended UX paradigm to show what's the default action of the dialog.
Blue focus ring: To indicate the currently focus element, which is the element that will get the enter/space keyboard event.

• The meaning of "Primary/Default button" is that it will get the Enter keyboard event unless another button has focus: pressing Enter (with focus anywhere in the dialog except other buttons) will trigger the default button.
• The meaning of "Focus ring" on any button (e.g. Cancel) is also that it will get the Enter keyboard event: pressing Enter will trigger that button.
• The very moment that you shift focus to another button which is not the default button, the default button will de facto no longer work as a default button, because pressing Enter will no longer trigger the default button, but the other button.
• Iow, you cannot have two buttons which accept Enter at the same time.

Since time immemorial, all UI's which I have seen indicate this by moving the default button styling (which used to be just a black or blue border) along with focus to the other button: So at any given time, there's only one button which has default button styling in the sense that it's marked to receive Enter. (Try it in Search and Replace dialog in Notepad and WordPad).

The new design depicted in comment 30 is ambiguous and wrong:

• Default button having blue background indicates that this button will get Enter keypress.
• Blue focus ring on the other button indicates that that button will get Enter keypress.
• Iow, there are two buttons concurrently styled to indicate that they will get Enter keypress, which is not possible.

So I'm with Zoe to question: What will pressing enter do in that situation?

I understand somewhat the intention to let the default button stand out even when another button has focus (hence default button temporarily suspended as a default), so as to keep guiding the user to the default action even when tabbing around other buttons. However, blue is a very unfortunate color for that, because blue has always been reserved for focus. For the same reason, I totally loathe the blue background color on checkboxes which aren't focused. We now have blue color all over the place which makes the actual focus point harder to find.
Perhaps if the default button background was green (for example, not sure about the color scheme...), I guess that would work better.
Or just drop the blue background when the default button is no longer active while another button has focus - user had a good chance to see the default button, but deliberately chooses to tab onto another button...

Phrased differently again, what we're lacking now is a difference in styling between a default button that will actually trigger on Enter (active) and a default button which won't (inactive because another button is focused).

We may or may not get used to this confusing design over time, but it looks less intuitive and requiring more active brain parsing and background knowledge to use. I guess it just happened for reasons of consistent coloring, paired with an oversight or ignorance about the logical necessity to indicate a non-active default button differently or not at all.

Comment 33

[Zoe Martin]

Attachment: 2021-09-17 22_09_09-Window.png

We didn't want to comment any further after getting the explanation from the UX lead engineer, but the design seems unfortunate. You have three different states: Blue button with no focus ring, attached here. Blue button with focus ring elsewhere (comment #30) and blue button with focus ring (next comment). Basically, you can't determine what effect pressing enter will have without inspecting all buttons and applying the following algorithm in your head: 1) Focus ring on button, that button takes effect 2) No focus ring on button, blue button takes effect. We haven't seen any other app showing this behaviour.

Comment 34

[Zoe Martin]

Attachment: 2021-09-17 22_16_03-Window.png

Blue button with additional focus ring.

Comment 35

[Alessandro Castellani [:aleca]]

Attachment: macos-dialog.jpg

Please, don't take Windows UI as the de-facto perfect standard of usability.
Windows UI is known in the design field for not being great, with many contradictions and many basic rule breakages, so if something is done "that way" in Windows it doesn't mean is the correct way.

A colored Primary/Default button is also used to indicate to users what's the "recommended" action in the current dialog.
It's a very very very old paradigm that has been around since the very early days of Machintosh 10.0, Cheetah, released in 2001.
See attachment for current macOS dialogs with primary Save button and visible focus ring on the Cancel button.

The paradigm is very simple and almost every application and OS is moving towards there:

• When the focus ring is not visible anywhere in any other area of the dialog, the primary button receives the Enter.
• When the focus ring is visible, the element with the focus receives the Enter.

Even the official design system of Windows 10 offers this optionally: https://docs.microsoft.com/en-ca/windows/apps/design/controls/dialogs-and-flyouts/dialogs#defaultbutton

You're also coming to this from the wrong assumption that the user will start hitting tab a million times and will get confused by the focus ring and primary button not matching style.
That's a non existing use case.
When the dialog opens up, the user knows that hitting enter will trigger the default action because that's the colored button.
If the user hits tab, the focus ring will appear, and at that point there's not really space for confusion since the focus ring represents the keyboard focus of which element the enter hit will trigger.

I really don't understand why we keep writing on a closed bug about a UX paradigm that has been widely used for the past 20 years.
Once again, the fact that Windows does something in a specific way it doesn't mean is the correct and only way. Windows has many usability problems, and the more a user uses a system, the less that user sees those problems, until they slowly turn into "comfortable usability patterns" because our brain is used to those, even if they're wrong.

Comment 36

[Thomas D. (:thomas8)]

Discarding a problem identified by power users and affecting the majority of Thunderbird users (given that Windows has the biggest market share) with exaggerations ("hitting tab a million times... non-existing use case") and distortions won't make the problem go away... I hear you about permanently indicating the default button somehow and that makes sense in a way... I think the confusion is about blue color no longer being a reliable indication of focus.

I bet if someone was to do a survey among less computer literate users and ask them about attachment 9241886 [details] - "which button do you think is currently active?" between a Cancel button with a thin blue border and an all-blue button, the majority will point the all-blue button, simply because it's over-salient. That's all good as long as it actually acts as a default button - the confusion starts when there are two buttons in the UI and both carry a notion of "active":

• You're saying that button with blue background means - gets Enter, so it's active.
• Then you're saying - yeah, but button with blue focus ring also means - gets Enter, so it's active - but alas - that necessarily implies that the blue background button will no longer be active. And yet it's still blue like before - meaning that the same styling can have two different meanings - active or inactive. That's what I find confusing. Of course - I can train my brain to ignore that confusion and take it as the new normal.

Maybe it's some users of the minority market share MacOS who got used to "comfortable usability patterns" , because their brain is used to that, even if it's wrong ;-)

Btw, I bet that Windows 10 even when it uses Accent Button for default button, will still change that styling when another button gets focus.

Comment 37

[Alessandro Castellani [:aleca]]

Discarding a problem identified by power users

This is not a problem!
Also, please stop using the term power users. There's no such thing as a power user for usability and interface best practices.

given that Windows has the biggest market share

So, are we suddenly building Thunderbird just for Windows?
Thunderbird is a standalone multi platform application that SHOULD and MUST have its own brand identity and look consistent. Letting the OS dictate everything about the UI creates so many problems, especially when the very own OS breaks very basic rules.
I don't see people complaining about Photoshop not looking like a Windows application, or not using macOS buttons.

I bet if someone was to do a survey among less computer literate users and ask them about attachment 9241886 [details] - "which button do you think is currently active?" between a Cancel button with a thin blue border and an all-blue button

This is the core of the problem.
You're using a unique state of focus moved by keyboard as something presented to the user by default, which never ever ever happens. The user is consciously moving the focus, and is never offered a situation where the focus is by default on another non-primary button when the dialog opens.
You're creating problems for situations that don't exist.

Btw, I bet that Windows 10 even when it uses Accent Button for default button, will still change that styling when another button gets focus.

I guess https://bugzilla.mozilla.org/show_bug.cgi?id=1731849#c2 goes against your wrong assumptions.

I'm sorry to be a bit salty on this, but this is absolutely absurd.
We're arguing about feelings and "what ifs" and ignoring 20 years of UX studies.
The only valid argument here is to maybe explore the possibility of having a different color/style for the focus, but that's also very trivial.

Comment 39

[Anje]

Talking about the image 'Save Message' window:
You say the 'Save' is the default selected button with focus when window pops up. But how would anyone know that. It serves no purpose colouring the entire background of button. It is just blue and very distracting. You actually have to Tab 3 times to get 'Save' with a blue border which does not exactly stand out that much. Some people do not have the best of eyesight. So I've never thought it had focus.

However, it does not look like it is selected. It is just blue background colour. I've never associated it as having focus because in Windows, you can open a window and 'File' is same colour as my Title bars - (a colour I set up), but if you click on 'Enter' nothing happens and Tab does not select the next item. The 'File' is not highlighted, not bold, no outline. So, I've always presumed that the coloured button etc just means advisory action or pretty for the sake of it - drawing your attention to select that options and has nothing to do with focus. Please do not use Windows as an example because it is not best practise ; it does not mean it has focus.

I like the action they use in OpenOffice because it is not ambiguous and it is simple.
The button with focus is identified because it has a blue outline which makes it look slightly larger.
So, this would mean the default 'save' would not be completely coloured blue, but it would automatically have a blue outline which makes it look slightly larger in size and it would improve the design if the font/text should be pronounced in bold when it has focus.

There is no need to have the background of buttons to be in a different colour. It is nothing but distracting and may influence you to select the wrong button or be confused. It is illogical to keep doing it when there is a better, simpler and non abiguous option.

Please can we keep it simple. Blue enhanced border and bold text if it has focus in all instances. Then everyone understands what it means.
As this area is in need of a fix, it would be an excellent move in the right direction to get rid of those ambigous coloured buttons and improve Thunderbird design.

Comment 40

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

@Anje I think you may be mixing the concepts of "focus" with "default", even though they are distinct. Whilst a dialog is open, the focus will not necessarily be on the default button and may be elsewhere. Moreover, the default button remains the default button even when it doesn't have focus. Hence we need two distinct states for "focus-visible" (focus ring) and "default" (background color).

(In reply to Anje from comment #39)

Talking about the image 'Save Message' window:
You say the 'Save' is the default selected button with focus when window pops up [...] You actually have to Tab 3 times to get 'Save' with a blue border which does not exactly stand out that much.

This is probably because you used a mouse to trigger the dialog, so the button may have ":focus" but not ":focus-visible" styling. You only see the focus ring after pressing "Tab" because it will trigger the ":focus-visible" styling. If you use a keyboard to trigger the dialog (such as Ctrl+W in this case) the focus ring should be displayed as soon as it opens.

Comment 41

[Anje]

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

@Anje I think you may be mixing the concepts of "focus" with "default", even though they are distinct. Whilst a dialog is open, the focus will not necessarily be on the default button and may be elsewhere. Moreover, the default button remains the default button even when it doesn't have focus. Hence we need two distinct states for "focus-visible" (focus ring) and "default" (background color).

The point I'm making is this. There is no point in a special colour for a default button if it may or may not have focus.
When you get the pop up it is blue but does not appear to have any focus.
Knowing what has focus is the most important thing you need to know.
Something with a special colour is meaningless unless you want to warn about something.
Just because it has been done by some software or Thunderbird in the past does not mean it was a good idea.

(In reply to Anje from comment #39)

Talking about the image 'Save Message' window:
You say the 'Save' is the default selected button with focus when window pops up [...] You actually have to Tab 3 times to get 'Save' with a blue border which does not exactly stand out that much.

This is probably because you used a mouse to trigger the dialog, so the button may have ":focus" but not ":focus-visible" styling. You only see the focus ring after pressing "Tab" because it will trigger the ":focus-visible" styling. If you use a keyboard to trigger the dialog (such as Ctrl+W in this case) the focus ring should be displayed as soon as it opens.

I would put my money on most people using the mouse and not Ctrl+W.
But whatever method you use, it should not be ambiguous and it is.
It is ambiguos because if you use a mouse then you have no idea what actually has focus.
Setting one button with a blue background regardless has no meaning. I've used Thunderbird for what seems like centuries and never understood why some buttons are blue for no apparent reason and why it is not visually clear if a blue button has focus or not.
I can see the additional border when it is added, but I can reasure you, some people would struggle with it.

There is no need for Thunderbird to choose what it thinks should be a default button and then colour it in a way that is deliberately confusing.

It would be a better more logical and non ambiguous approach to either remove the blue background and use a blue border OR use the Blue background to denote what has focus but not both. It is by default set as focused and the user will know it.

This would mean the 'Save' button would auto have a blue border by default when pop up window opens regardless of whether you use a mouse or buttons or as I do a combination. It is irritating to use a mouse to activate that pop up and then use tab - 3 times to get what is clearly the correct forus on correct button before you press Enter. That is not good.
As I said there is no reason for choosing a default button and giving it a colour. It serves no purpose, it is an old design that should be dropped, but having a button set up with auto focus which is very clear to all people no matter what eyesight problem - is useful.

Comment 42

[Alessandro Castellani [:aleca]]

(In reply to Anje from comment #41)

The point I'm making is this. There is no point in a special colour for a default button if it may or may not have focus.
When you get the pop up it is blue but does not appear to have any focus.
Knowing what has focus is the most important thing you need to know.
Something with a special colour is meaningless unless you want to warn about something.
Just because it has been done by some software or Thunderbird in the past does not mean it was a good idea.

I'm sorry but this point is completely wrong and it goes against basic UX paradigm.

When a dialog popups, if you hit "Enter" on your keyboard, the dialog will trigger it's default behavior.
How would you know what is the default? With the "primary" button having a primary color.

As Henry said, the default dialog action and the action triggered from a focused element are completely different and having those visually "merge" is a very wrong UX paradigm and goes against standard heuristics.

We "don't do things because other softwares do"!

Comment 43

[Alessandro Castellani [:aleca]]

Also, this bug has been resolved and a decision has been made.
Please stop commenting on this bug.

If you want, you can open a new bug and propose a patch, but Bugzilla is not a discussion forum.