1921959 - New tab button in sidebar is not clickable from screen edges (Fitts' law)

Status: REOPENED

(Firefox :: Sidebar, defect, P2)

Description

[Kestrel]

Attachment: New tab button only exception to Fitts' law

STR:

1. Start with sidebar.verticalTabs = true and sidebar.revamp = true.
2. Maximize the window.
3. Click the extreme edge of the screen next to the new tab button.

Expected:
New tab button can be clicked from screen edges like other tabs.

Actual:
Nothing happens when clicking the screen edge next to the new tab button.

Comment 1

[Sarah Clements [:sclements]]

I talked to UX about this and this isn't viewed as an issue since the mouse isn't even on the button.

Comment 2

[Dão Gottwald [:dao]]

(In reply to Sarah Clements [:sclements] from comment #1)

I talked to UX about this and this isn't viewed as an issue since the mouse isn't even on the button.

I'm not sure I understand. Fitts' law is something we've cared about for a long time. This seems to work as expected for tabs and buttons at the button of the sidebar, and based on tgiles' and mstriemer's work I assume this is intentional. Why should the new tab button work differently?

Comment 3

[Sarah Clements [:sclements]]

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

(In reply to Sarah Clements [:sclements] from comment #1)

I talked to UX about this and this isn't viewed as an issue since the mouse isn't even on the button.

I'm not sure I understand. Fitts' law is something we've cared about for a long time. This seems to work as expected for tabs and buttons at the button of the sidebar, and based on tgiles' and mstriemer's work I assume this is intentional. Why should the new tab button work differently?

I asked Yulia about it and she said "the mouse isn't even on the button [in the regarding], so it's okay that it doesn't react in this case".

We can reopen if you feel strongly but its not something that is a high priority.

Comment 4

[Dão Gottwald [:dao]]

(In reply to Sarah Clements [:sclements] from comment #3)

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

I'm not sure I understand. Fitts' law is something we've cared about for a long time. This seems to work as expected for tabs and buttons at the button of the sidebar, and based on tgiles' and mstriemer's work I assume this is intentional. Why should the new tab button work differently?

I asked Yulia about it and she said "the mouse isn't even on the button [in the regarding], so it's okay that it doesn't react in this case".

Again, this is true for both tabs and those other buttons. It's been true for many years for buttons in the navigation toolbar as well. In fact, I believe this was the primary motivation for bug 1902083. Tim, can you confirm?

We can reopen if you feel strongly but its not something that is a high priority.

We could certainly ship without this being fixed, but I feel strongly this is a legitimate bug.

Comment 5

[Tim Giles [:tgiles]]

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

Again, this is true for both tabs and those other buttons. It's been true for many years for buttons in the navigation toolbar as well. In fact, I believe this was the primary motivation for bug 1902083. Tim, can you confirm?

Essentially, yes. The behavior of the first and last buttons in the toolbar motivated adding the configurable padding for the moz-button component. As those toolbar buttons have additional padding that makes them easier to click, especially when the window is maximized. As far as I understand it, we are complying with the AA requirement from WCAG since the new tab button's clickable area is at least 24 by 24 CSS pixels. However, we should strive towards AAA where possible to improve the user experience for more users. The Target Size (Level AAA) success criterion states that targets for pointer events should be at least 44 by 44 CSS pixels, as well as increasing the target area when "the control is positioned where it will be difficult to reach, e.g. is near the edge of the screen." (emphasis mine). This does not mean we need to make the visible hover state rectangular, just means we should behave similarly to the first button and the last button in the nav toolbar.

We can reopen if you feel strongly but its not something that is a high priority.

We could certainly ship without this being fixed, but I feel strongly this is a legitimate bug.

Seconded, I believe this is a legitimate bug/enhancement but one that can be shipped.

Comment 6

[Sarah Clements [:sclements]]

Thanks for explanations Tim and Dão - I hadn't known the backstory behind our historical support for Fitt's Law or full context on the moz-button changes.

Comment 7

[Will]

Folks please, I know vertical tabs is still in development but this one is a no brainer, 4 months for something as obvious as this is a bit silly. The tabs respecting Fitts' Law when the window is maximized but the new tab button not makes for one of the most frustrating user experiences I've come across because I get used to the bliss that is Fitts' Law when targeting tabs, but it doesn't work with the new tab button. I think there must be some confusion here. For example, when Firefox is in its normal horizontal tabs mode, imagine if only the new tab button didn't respect Fitts' Law? There would be endless complaints about it, because it would be ridiculous and frustrating.

Comment 8

[Will]

Only sharing this because, amazingly, I just found out that Chrome actually did accidentally break the “rule of the infinite edges” for the new tab button and got a bunch of complaints and bugs filed for it https://issues.chromium.org/issues/40152330

So now we have real proof and know for sure that users aren't going to like this once vertical tabs ships, it really could make a bad first impression for vertical tabs.

Comment 9

[Will]

Please at least increase to P2. Chrome had the exact same bug and designated it a P1. There was many user complaints about it https://issues.chromium.org/issues/40152330

The new tab button in Firefox's "normal" horizontal tabs mode respects Fitts' Law when the window is maximized, I cannot think of a reason why only the new tab button should not follow Fitts' Law when in vertical tabs mode. We must remember that the new tab button is one of the most commonly clicked buttons in the browser, this issue is not a low priority edge case.

Comment 10

[Will]

Folks, this is such a painful issue :( I run into this every single time I go to click the new tab button! Please if you can fit this in soon, it would make such a difference for a lot of vertical tabs users!

Comment 11

[Will]

I apologize for pinging this one again but I thought it's worth adding that the new tab button in Microsoft Edge's vertical tabs mode follows Fitts' Law, so you could give this bug the parity-edge tag because people used to Edge's vertical tabs new tub button experience probably will feel the regression if they try Firefox. Also, Microsoft Edge's vertical tabs mode having the new tab button follow Fitts' Law for so long proves that it's a safe, low risk, tried and tested UX. There should be no concerns about doing this.

Comment 12

[Will]

Folks, these Fitts' Law issues are not low priority, just look at all the duplicates and "See Also's" https://bugzilla.mozilla.org/show_bug.cgi?id=1993474

it also got posted and upvoted on r/Firefox https://www.reddit.com/r/firefox/comments/1ouv0m4/how_do_i_removereduce_this_extra_space_above_the/

Comment 13

[Will]

I'm really sorry for commenting yet again but since the new tab button is getting updated/changed for the Nova redesign, please just make the click target bigger so this can be solved/fixed! This is such a painful papercut :(