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

Status: REOPENED

(Firefox :: Sidebar, defect, P3)

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.