New issue
Advanced search Search tips

Issue 848429 link

Starred by 7 users

Issue metadata

Status: Fixed
Owner:
Closed: Sep 14
Cc:
Components:
EstimatedDays: 2
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 3
Type: Bug

Blocking:
issue 822063
issue 847894



Sign in to add a comment

New Tab Button: Fitts' Law

Project Member Reported by pkasting@chromium.org, May 31 2018

Issue description

The New Tab button should take advantage of Fitts' Law appropriately in refresh.  We certainly don't extend to the window side edge, we may not be correct in how we extend to top.

2 days, mostly because I need to worry about things like "is TRAILING actually at the window edge".

P2; we shouldn't ship without this (and we probably don't want to wait too long on it because it makes the LEADING position more sensical).
 
Blocking: 847894
Note to self: if the NTB is after the tabs, make sure the first tab gets Fitts' Lawed.
Note to self: Be careful about assuming that LEADING means "at window left edge" -- it may not for CrOS teleported windows (see  bug 834524 ).
Status: WontFix (was: Assigned)
The NTB is now in the trailing position. It's not clear that we need this for the first tab for M69. If the first tab absolutely needs special treatment, let's open a new bug.
Labels: -Pri-2 Pri-3
Owner: ----
Status: Available (was: WontFix)
Let's leave this open for ensuring the vertical extension is correct and for handling horizontal extension for LEADING/TRAILING (since we're not closing the door on future use of those yet) but P3 it as not-blocking-ship-anymore.
the new tab button position is a terrible mistake. yet another reason to dump chromium, along with it's retarded 3-month hardcoded browsing history limit. thank god firefox is usable nowadays... goodbye chrome.
Using the same position we've always used is a terrible mistake?
"  @17: This is working as designed.  Pinning the new tab button to a fixed position allows it to be more easily targeted as the number of tabs changes, but it's not going to change where new tabs open, since disturbing the order of the initial tabs in the strip breaks a lot of workflows.  "

                                  - pkasting@chromium.org (On  issue 822063 )


The new position of the NTB (Fixed at the left before the tabs <Windows>), was 
perfect, after getting used to it(It DEFINITELY needed some getting used to).

In Chrome canary 69.0.3478.0, NTB is switched back to the old pre-material refresh style. Please tell me this is a bug and not intended behaviour.
While there are reasons why a fixed NTB position has advantages (as you quote above), after testing, feedback, and reflection, the decision is to leave the NTB after the tabs as it was in previous versions of Chrome.  So it is intended behavior, not a bug.
Bummer, I liked the fixed position. I think it would have been problematic in Chrome OS when using multi-profile mode though. 
The fixed New Tab button is so much better that there should be an option in the settings, it's definitely worth the added complexity. You're right to not switch it on people though, there would be backlash. Also, maybe have the new tab button fixed on new installs? 
Labels: Group-New_Tab_Button
Cc: viswa.karala@chromium.org susan.boorgula@chromium.org
 Issue 857078  has been merged into this issue.
Labels: M-70 Target-70
Labels: -M-70 -Target-70 M-71 Target-71
Owner: dfried@chromium.org
Status: Assigned (was: Available)

Comment 17 Deleted

Failure to conform to Fitts Law only happened in the case described by  issue 863228  (mixed-monitor DPI mode on Windows). This bug was fixed as a side effect of https://chromium-review.googlesource.com/c/chromium/src/+/1214747

Now the New Tab button should have a hit-test area that touches the top of the window whenever Chrome is maximized.

I'm marking this fixed but we should verify on all affected platforms.
I suspect this isn't actually fixed for LEADING/TRAILING NTB positions but I also suspect that the likelihood of those ever shipping is dropping, so maybe it doesn't matter.

Sign in to add a comment