1560540 - Twisty becames small on recent versions of Firefox

Status: VERIFIED FIXED

(Toolkit :: Themes, defect, P3)

Description

[Alex ARNAUD]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

1. I've upgraded from Firefox ESR 60 to Firefox 68b12
2. To see twisty arrows you can open the history pane

Actual results:

The twity size has been reduced so it's now hard to see them

Expected results:

The size of twisty should be the same as before even the design has changed.

This new behavior impact low-vision people, elderly and all people with seeing disabilities.

Comment 1

[Alex ARNAUD]

@JorgK: This issue comes from Firefox but highly impact Thunderbird because there are many Twisty on Thunderbird. It prevents us to consider migrating on versions with those little arrows.

Best regards,
Alex.

Comment 2

[Jorg K (CEST = GMT+2)]

Richard, are our twisties also smaller? If so, can we look at it in another bug please.

Comment 3

[Richard Marti (:Paenglab)]

The twisties are on all platforms the same. When I compare with the ones from TB/FX 60 on Ubuntu or Mint then the new, no more system twisties are bigger than the system twisties from TB/FX 60.

Alex, do you use a special theme with big twisties?

Comment 4

[Alex ARNAUD]

Attachment: Thunderbird 60 twisty

Comment 5

[Alex ARNAUD]

Attachment: Thunderbird 68b2 twisty.png

I've added both screenshot of TB 60 and TB 68b2. For me the difference looks substantial (I'm a low-vision person).

Best regards,
Alex.

Comment 6

[Alex ARNAUD]

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

Alex, do you use a special theme with big twisties?

I'm using the GTK3 High Contrast theme.

Best regards,
Alex.

Comment 7

[Jorg K (CEST = GMT+2)]

Hmm, the size is about the same, but it's now no longer a filled triangle but an arrow like this >.

Comment 8

[Samuel Thibault]

The size is not that much the same (almost 8 pixels now, vs a bit more than 10 pixels before). Being not filled also makes it less visible, so it should on the contrary be made a bit bigger.

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:asa, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 10

[Alex ARNAUD]

Do you have seen the comment #8 ?

A reduction of 20% seems to me a substantial reduction.

What do you think about this one?

Best regards,
Alex.

Comment 11

[Jorg K (CEST = GMT+2)]

Yes, I've seen the comment, but I don't know what to do about it really since I don't work on the themes.

Comment 12

[Alex ARNAUD]

Hello Julien,

I'm not part of Mozilla but I'm visual-impaired and concerned about accessibility of Mozilla product. This issue is real regression from a low-vision perspective.

Could we imagine a collaboration with the design team to make this fixed ? The accessibility team seems overloaded and doesn't have the time to figure out P3 issues as I can see.

The reason I ask you is because I assume increasing the size of the new twisty shouldn't be a huge amount of work for the design team.

Thank you in advance and for the work Mozilla does to improve Firefox.

Best regards,
Alex.

Comment 13

[Julien Cristau [:jcristau]]

Hi Alex,

You may want to bisect this to figure out exactly when it changed and why, then figure out a way to reconcile that with the accessibility concern. Plus that'll help put this bug in front of the people who made the change.

Comment 14

[Samuel Thibault]

Looking at the history of the files I could find, there is:

# User Richard Marti <[e-mail]>
# Date 1529846793 -7200
#      Sun Jun 24 15:26:33 2018 +0200
# Node ID 93972d67be617f39abd66ef8de1063047b7213ba
# Parent  839c17021ae03dd14eef2dfa10b9208250f5cfff
Bug 1400266 - Use SVG icons for the twisties on Linux. r=dao

It's probably worth trying to target this before a whole bisection.

Comment 15

[Samuel Thibault]

(Uh, sorry about the hg # signs which got rendered...)

Comment 16

[Samuel Thibault]

Yes, that seems to be it, so Bug 1400266, I'll attached screenshots for comparison.

Comment 17

[Samuel Thibault]

Attachment: 2018-06-29-10-03-24.png

This is with nightly as taken from https://archive.mozilla.org/pub/thunderbird/nightly/2018/06/2018-06-29-10-03-24-comm-central/

Comment 18

[Samuel Thibault]

Attachment: 2018-06-30-10-02-27.png

And this is nightly as taken from https://archive.mozilla.org/pub/thunderbird/nightly/2018/06/2018-06-30-10-02-27-comm-central/

Comment 19

[Samuel Thibault]

Richard, it's the move from .png to .svg which made the twisties much less visible (not filled, and smaller). Personally I'm not using a high-contrast theme, but even there the difference is notable (and as can be seen on both screenshots, the twisty pointing down a bit further on the right is much bigger).

Comment 20

[Samuel Thibault]

Alex, could you also check with your high-constrast theme?

Comment 21

[Alex ARNAUD]

(In reply to Samuel Thibault from comment #20)

Alex, could you also check with your high-constrast theme?

Yes, I confirm, I see the regression between the two builds you've mentioned with the build-in GTK3 Hight Contrast theme.

Many thanks Samuel for looking at this.

Comment 22

[Pascal Chevrel:pascalc]

Asa, could we get this one prioritized please?
Also needinfoing Martin as this seem to happen with Linux on a hight-contrast GTK theme so it's not clear to me if the accessibility impact is due to the Firefox theming or our GTK ssupport in a high-contrast context.

Comment 23

[Asa Dotzler [:asa]]

I spoke with Stephen about this a while back and it sounds like this sized control is a part of our general toolkit now (and used elsewhere?) In this case, the entire label is focusable and can be used to expand/collapse, so this bug is not a hit target issue as much as an informational one, I think. By that I mean, can the user distinguish the collapsed from the expanded state at this smaller size. Arnaud, do I have that right?

Comment 24

[Alex ARNAUD]

(In reply to Asa Dotzler [:asa] from comment #23)

I spoke with Stephen about this a while back and it sounds like this sized control is a part of our general toolkit now (and used elsewhere?) In this case, the entire label is focusable and can be used to expand/collapse, so this bug is not a hit target issue as much as an informational one, I think. By that I mean, can the user distinguish the collapsed from the expanded state at this smaller size. Arnaud, do I have that right?

Yes, indeed. with this new size twisty looks like a blot on the screen and it's more an effort to see them.

Best regards.

Comment 25

[Martin Stránský [:stransky] (ni? me)]

Due to this part of the patch (Bug 1400266):

• -moz-appearance: treetwistyopen;

• background-image: url("chrome://global/skin/tree/twisty-expanded.svg");

twisty property is no longer set by system Gtk theme but it's always used mozilla internal graphics/size - the fix may be a part of Firefox internal HighContrast theme then.

Comment 26

[Alex ARNAUD]

twisty property is no longer set by system Gtk theme but it's always used mozilla internal graphics/size - the fix may be a part of Firefox internal HighContrast theme then.

On Linux, we do not have the support for the Firefox high contrast theme.

I'm sorry for my innocent question: why do not letting the theme setting the twisty size? How we could improve the situation without the Firefox support the high contrast theme?

Best regards.

Comment 27

[Martin Stránský [:stransky] (ni? me)]

(In reply to Alex ARNAUD from comment #26)

twisty property is no longer set by system Gtk theme but it's always used mozilla internal graphics/size - the fix may be a part of Firefox internal HighContrast theme then.

On Linux, we do not have the support for the Firefox high contrast theme.

Sorry, you're right. I was confused by the build-in Light/Dark themes.

I'm sorry for my innocent question: why do not letting the theme setting the twisty size? How we could improve the situation without the Firefox support the high contrast theme?

I don't know, see Bug 1400266 for details. Dao, do you know why the size is no longer read from system theme?

Comment 28

[Dão Gottwald [:dao]]

(In reply to Martin Stránský [:stransky] from comment #27)

I don't know, see Bug 1400266 for details. Dao, do you know why the size is no longer read from system theme?

If I remember correctl UX wanted us to use the custom twisties instead of the OS-provided ones.

Comment 29

[Pascal Chevrel:pascalc]

Dao, is there something we can do to fix the accessibility regression here? Should we track that for 71?

Comment 30

[Alex ARNAUD]

(In reply to Pascal Chevrel:pascalc from comment #29)

Dao, is there something we can do to fix the accessibility regression here? Should we track that for 71?

Is there any news on this ? How we could help Mozilla to be involved on this one?

Comment 31

[Dão Gottwald [:dao]]

This bug needs a UX decision before it's actionable. For instance we could just use a bigger SVG.

Comment 32

[Pascal Chevrel:pascalc]

(In reply to Dão Gottwald [::dao] from comment #31)

This bug needs a UX decision before it's actionable. For instance we could just use a bigger SVG.

Who should needinfo for this UX decision?

Comment 33

[Alex ARNAUD]

Could it be possible to raise the priority of this issue? We've blocked all Firefox / Thunderbird upgrade until the fix of this issue because it highly impacted our visual-impaired users.

Comment 34

[Jean-Philippe MENGUAL]

Hi,

(In reply to Dão Gottwald [::dao] from comment #31)

This bug needs a UX decision before it's actionable. For instance we could just use a bigger SVG.

Maybe you could remember the terms of the UX choice for the manager? Should he "cut off" between "using a svh images" or "the OS properties", or "the internal Firefox properties"? Is it a technical decision or imply a UX feedback? Are other possible choices?

regards

Comment 35

[Jonathan Michalon]

I can provide a patch that enlarge the SVG a little and raises the limits in the CSS files. I've a PoC for one of the occurrences which works well (history panel in Firefox). Now if it's an UX decision and it will never be merged I prefer to know it beforehand. :)

Comment 36

[Jonathan Michalon]

Attachment: Bug 1560540 - Set custom twisty's size to 12px. r=dao

Comment 37

[Dão Gottwald [:dao]]

(In reply to Jonathan Michalon from comment #35)

I can provide a patch that enlarge the SVG a little and raises the limits in the CSS files. I've a PoC for one of the occurrences which works well (history panel in Firefox). Now if it's an UX decision and it will never be merged I prefer to know it beforehand. :)

Yeah, it is a UX decision. Could you please provide before / after screenshots for comparison to help UX people make that call?

Comment 38

[Jonathan Michalon]

Attachment: before and after twisty growth

Here you are: before with stock 68 ESR and after with nightly and bigger twisty (built from the provided patch).

Comment 39

[Asa Dotzler [:asa]]

This is going to be up to our UX team to decide but I'm interested in a clarification here.

Is the twisty now completely invisible for affected users or just not visible enough to distinguish open vs closed state? It seems like open closed state can be determined by the visibility, or not, of an indented sub list of items. What precisely can affected users not easily do that they could do before?

Comment 40

[Alex ARNAUD]

(In reply to Asa Dotzler [:asa] from comment #39)

Is the twisty now completely invisible for affected users or just not visible enough to distinguish open vs closed state? It seems like open closed state can be determined by the visibility, or not, of an indented sub list of items. What precisely can affected users not easily do that they could do before?

The twisty is too small to be easily visible by a low-vision or elderly person and in consequence the amount of space to click on it is reduced so to click on it you need to be really precise.

Also as mentioned by my colleague the current size of the twisty is inferior to the text size and so there is no benefit to reduce the twisty size.

Best regards.

Comment 41

[Asa Dotzler [:asa]]

(In reply to Alex ARNAUD from comment #40)

The twisty is too small to be easily visible by a low-vision or elderly person and in consequence the amount of space to click on it is reduced so to click on it you need to be really precise.

The entire text label is clickable, not just the twisty.

Comment 42

[Alex ARNAUD]

How we could obtain an answer from the design team?

As stated by mail to Asa I'm afraid to wait one year without having a decision on this.

We're forced to let our users to Firefox and Thunderbird 60 in part because there is this issue.

Comment 43

[Alex ARNAUD]

(In reply to Asa Dotzler [:asa] from comment #41)

(In reply to Alex ARNAUD from comment #40)

The twisty is too small to be easily visible by a low-vision or elderly person and in consequence the amount of space to click on it is reduced so to click on it you need to be really precise.

The entire text label is clickable, not just the twisty.

I was not aware of that and I think the end-user too. It's almost always a issue for low-vision users I train because they've difficult to find where to target and so more it is small more it is difficult to see and target the right area.

(For the reminder I'm myself a screen magnifier users at zoom level 5 and I'm also impacted by this)

Comment 44

[Sylvestre Ledru [:Sylvestre]]

Sure. I just asked to the team slack channel for help here.
Please ping me if we don't have an update in a week.

Comment 45

[Mike Hommey [:glandium]]

The twisty is too small to be easily visible by a low-vision or elderly person

Playing Devil's advocate here. Isn't the text too small on that screenshot for low-vision or elderly people? Presumably, the twisty is bigger if the font is bigger?

Comment 46

[Alex ARNAUD]

(In reply to Mike Hommey [:glandium] from comment #45)

The twisty is too small to be easily visible by a low-vision or elderly person

Playing Devil's advocate here. Isn't the text too small on that screenshot for low-vision or elderly people? Presumably, the twisty is bigger if the font is bigger?

Unfortunately not, expect if I'm wrong the twisty is at a fixed size.
(I'm increase the default text size on my computer for my own needs)

Comment 47

[Alex ARNAUD]

Attachment: font_size_18_twisty_fixed.png

I'm providing a screenshot at font size 18 where we could see the fixed size.

Comment 48

[Dão Gottwald [:dao]]

So maybe the right fix here is to make the twisty size depend on the font-size. Should be doable since it's SVG, although we should double-check that it scales well.

Comment 49

[Jonathan Michalon]

While switching from 8 px to 12 px (hardcoded in CSS), I tried to make it scale to something like height: 1em or width: 20px but it was too naive. It makes room around it but the actual render of the SVG stick to the size defined inside the SVG. This is why the patchset also modifies the SVG. If it's not on purpose and doable, this sounds good indeed. Could also be plain characters like '❯' that would scale and allow to drop the SVG, but again it depends on the UX reason, why it has been moved to custom size.

Comment 50

[Alex ARNAUD]

(In reply to Dão Gottwald [::dao] from comment #48)

So maybe the right fix here is to make the twisty size depend on the font-size. Should be doable since it's SVG, although we should double-check that it scales well.

We'd like it too but as we're not Firefox developer and because we usually work in accessibility code it's difficult for us to provide more than the patch we made.

Is it possible to make it bigger and in another issue we could discuss to make it scalable ?

Comment 51

[Stephen Horlander [:shorlander]]

Attachment: twisties-and-arrows.zip

(In reply to Alex ARNAUD from comment #40)

(In reply to Asa Dotzler [:asa] from comment #39)

Is the twisty now completely invisible for affected users or just not visible enough to distinguish open vs closed state? It seems like open closed state can be determined by the visibility, or not, of an indented sub list of items. What precisely can affected users not easily do that they could do before?

The twisty is too small to be easily visible by a low-vision or elderly person and in consequence the amount of space to click on it is reduced so to click on it you need to be really precise.

Also as mentioned by my colleague the current size of the twisty is inferior to the text size and so there is no benefit to reduce the twisty size.

Hi! I agree we can increase the visual weight of the twisties to be more visible. I’m attaching some larger optimized SVGs. We should also update the arrow icon we use for panels since they share the same shape (https://searchfox.org/mozilla-central/source/browser/themes/shared/icons/back-12.svg)

Some things worth noting:

• The visual size of the image should not have affected the size of the click/hit area
• I noticed in the Thunderbird screenshots several other icons that have similar visual weighting issues

With regards to scaling the twisty based on text size: I think that should be out of scope for this bug. We have a lot of icons in the UI that are related to labels and we shouldn’t inconsistently scale one but not the others. I think it should be a broader discussion about if and how we should treat overall UI scaling issues.

Comment 52

[Alex ARNAUD]

Hello Sylvestre,

We're confused, we don't know which one should take a decision and what you expect from to update our patch.

Best regards.

Comment 53

[Sylvestre Ledru [:Sylvestre]]

Tim, is that something you could help with ? :)
thanks

Comment 54

[Tim Nguyen :ntim]

Attachment: Bug 1560540 - Update twisty images to be larger.

Comment 55

[Tim Nguyen :ntim]

Attachment: Screenshot of patch

Maybe it's just my personal preference, but I find the new twisties oversized, especially in the bookmarks sidebar.

Comment 56

[Alex ARNAUD]

(In reply to Tim Nguyen :ntim from comment #55)

Created attachment 9128083 [details]
Screenshot of patch

Maybe it's just my personal preference, but I find the new twisties oversized, especially in the bookmarks sidebar.

This seems good to me, thanks for proposing this change.

Do you need to add a reviewer and assign the issue to you?

Comment 57

[Tim Nguyen :ntim]

Added a reviewer and requested design review. I'm not convinced the new twisties look better though.

Comment 58

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2062868d7c96
Update twisty images to be larger. r=dao

Comment 59

[Arthur Iakab [arthur_iakab]]

https://hg.mozilla.org/mozilla-central/rev/2062868d7c96

Comment 60

[Sylvestre Ledru [:Sylvestre]]

Alex, it should be available in nightly in the next few hours. Could you please check if it works correctly for you?

Comment 61

[Alex ARNAUD]

I confirm that it is now fixed, many thanks.

Richard, do you think we should submit the patch for Thunderbird or Thunderbird will automatically get this patch?

Best regards.

Comment 62

[Richard Marti (:Paenglab)]

For the trees it takes the changes automatically. But there are other places I need to adapt the new size.

Comment 63

[Alessandro Castellani [:aleca] - PTO until Nov 16]

Attachment: tb-twisty-too-big.png

For what it's worth, I kind of disagree with this change.

Maybe it's just my personal preference, but I find the new twisty oversized, especially in the bookmarks sidebar.

As Tim rightly pointed out, the new sizing makes the twisty icons look bloated and out of balance with the rest of the content.
With this size, the twisty icons now gain the focal point on pretty much every location they're used, which is very distracting.
In the message pane, the size and thickness of the icons make them look disconnected from the rest of the design.

The underlying accessibility issue wasn't the size of the icon, but rather the inability of that icon to scale alongside the font-size variation. Those twisty icons should scale as the font-size does to maintain the predefined visual balance, and not overblown them when dealing with regular font scaling.

Comment 64

[Alex ARNAUD]

The underlying accessibility issue wasn't the size of the icon, but rather the inability of that icon to scale alongside the font-size variation. Those twisty icons should scale as the font-size does to maintain the predefined visual balance, and not overblown them when dealing with regular font scaling.

OK Alessandro. I understand your point. Could we agree on this:

• it's better to have big twisty until the twisty will be scaled
• Without having twisty big it is difficult for visual-impaired or elderly peole to see them
• On my settings, I would prefer to have twisty bigger than it is now

@Samuel: does the new twisty are bigger than the previous one on TB 52?

Comment 65

[Tim Nguyen :ntim]

One thing that could be done to alleviate the visual weight is reducing the opacity of the twisty, and maybe slightly increasing the margin.

:aleca, do you mind filing a new bug to discuss this ? Thanks :)

Comment 66

[Alessandro Castellani [:aleca] - PTO until Nov 16]

(In reply to Tim Nguyen :ntim from comment #65)

:aleca, do you mind filing a new bug to discuss this ? Thanks :)

Done: bug 1619697 :D

Comment 67

[Samuel Thibault]

Attachment: thunderbird 52 twisty

Comment 68

[Samuel Thibault]

Attachment: firefox twisty before fix

Comment 69

[Samuel Thibault]

Attachment: firefox twisty after fix

Comment 70

[Samuel Thibault]

I have attached snapshots for thunderbird 52, and firefox before and after the fix.

In thunderbird 52 on the x axis we had 8 dark gray pixels and 2 light gray pixels for antialias
In firefox before the fix we had 6 black pixels and 2 gray pixels for antialias
In firefox after the fix we have 10 black pixels and 2 gray pixels for antialias

So yes, the fix makes the twisty bigger than it was in thunderbird 52.
A difference, however, is that the thunderbird 52 twisties were full triangles, thus more visible.

Comment 71

[Julien Cristau [:jcristau]]

Hey Tim, do you think we should back this out for 75 to address the regressions, or are we good as-is?

Comment 72

[Alex ARNAUD]

(In reply to Julien Cristau [:jcristau] from comment #71)

Hey Tim, do you think we should back this out for 75 to address the regressions, or are we good as-is?

Doing this will create a a11y regression as twisty will became really small. IMHO we couldn't revet a11y fixes and keep a11y regression without reverting the change that has produced this issue.

Comment 73

[Julien Cristau [:jcristau]]

No it wouldn't, it would restore things to what they were in 74.

Comment 74

[Alex ARNAUD]

jfjjj(In reply to Julien Cristau [:jcristau] from comment #73)

No it wouldn't, it would restore things to what they were in 74.

If we revert the change which has fixed this issue, the issue we've tried to figure out here we'll come back and so this will make twisty small again.

Really as it impacts low-vision person like me it is a a11y regression IMHO.

I hope to see this issue fixed with the regressed one and not just come back in 74 and being forced to switch a very old release of Firefox to have twisty at a visible size.

Best regards.

Comment 75

[Tim Nguyen :ntim]

There's only 1 regression that's essential to fix, it's bug 1625331. I'm still waiting on review for this one. I think it should land in time.

The other one is probably more of an enhancement.

Comment 76

[Julien Cristau [:jcristau]]

We're out of betas for 75, there's not really a "in time" anymore.

Comment 77

[Tim Nguyen :ntim]

(In reply to Julien Cristau [:jcristau] from comment #76)

We're out of betas for 75, there's not really a "in time" anymore.

If we can't uplift bug 1625331 to 75, I guess a backout from Firefox 75 also works, but uplifting bug 1625331 is just as low risk as a backout IMO.

Comment 78

[Julien Cristau [:jcristau]]

Backed out for 75: https://hg.mozilla.org/releases/mozilla-release/rev/cfa12721e4dec94b2dda7736a691c8f5e0ed9c60

Comment 79

[Timea Zsoldos [:tzsoldos], Desktop QA]

I have reproduced this issue using Firefox 68.0b12 on Win 8.1 x64.
I can confirm this issue is fixed, I verified using Firefox 76.0b8 on Win 8.1 x64, macOS 10.15 and Ubuntu 18.04 x64.