.. maybe placement. Placement needs to be tested and evaluated which might need another flags entry.

.. also parts of this might already be covered by touchable Chrome.

Relevant Touchable stuff is probably on Issue 805762 and Issue 805245. (tracker: Issue 801584)

From go/chrome-ux-gm2:
https://docs.google.com/presentation/d/1EO7TOpIMJ7QHjaTVw9St-q6naKwtXX2TwzMirG5EsKY/edit#slide=id.g36e7d8d795_33_180

Tearsheet: go/chrome-ux-gm2-core

Deleted: Screen Shot 2018-04-18 at 5.06.38 PM.png 145 KB

	Screen Shot 2018-04-18 at 5.06.38 PM.png 145 KB View Download

Deleted: Screen Shot 2018-04-18 at 5.07.00 PM.png 130 KB

	Screen Shot 2018-04-18 at 5.07.00 PM.png 130 KB View Download

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/62fdfa68da23bfa6920b919d6666a86f7388b039

commit 62fdfa68da23bfa6920b919d6666a86f7388b039
Author: Peter Kasting <pkasting@chromium.org>
Date: Thu Apr 19 02:50:52 2018

Initial work for material refresh new tab button.

* Corner metric getter need not take a Rect, just a Size.  This could have been
  a separate patch but I was lazy.
* Update touchable to use GetCornerRadiusMetric() instead of hardcoding.
* Make most New Tab Button "touchable" conditionals apply to all newer material
  modes.
* Reorder some code in the paint function so I can omit painting fill/stroke in
  material refresh.  No significant changes to the blocks that got moved.

Still to do:

* This is probably the wrong icon
* The button's in the wrong position
* It's not clear we want high emphasis in material refresh
* I don't know if these are the right ink drop/ripple effects

BUG= 822063 
TEST=none

Change-Id: I7572e9be176553a747187c6b2327c7060776eb45
Reviewed-on: https://chromium-review.googlesource.com/1005973
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Allen Bauer <kylixrd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#551926}
[modify] https://crrev.com/62fdfa68da23bfa6920b919d6666a86f7388b039/chrome/browser/ui/layout_constants.cc
[modify] https://crrev.com/62fdfa68da23bfa6920b919d6666a86f7388b039/chrome/browser/ui/views/harmony/chrome_layout_provider.cc
[modify] https://crrev.com/62fdfa68da23bfa6920b919d6666a86f7388b039/chrome/browser/ui/views/harmony/chrome_layout_provider.h
[modify] https://crrev.com/62fdfa68da23bfa6920b919d6666a86f7388b039/chrome/browser/ui/views/harmony/material_refresh_layout_provider.cc
[modify] https://crrev.com/62fdfa68da23bfa6920b919d6666a86f7388b039/chrome/browser/ui/views/harmony/material_refresh_layout_provider.h
[modify] https://crrev.com/62fdfa68da23bfa6920b919d6666a86f7388b039/chrome/browser/ui/views/location_bar/location_bar_view.cc
[modify] https://crrev.com/62fdfa68da23bfa6920b919d6666a86f7388b039/chrome/browser/ui/views/tabs/new_tab_button.cc
[modify] https://crrev.com/62fdfa68da23bfa6920b919d6666a86f7388b039/chrome/browser/ui/views/tabs/new_tab_button.h
[modify] https://crrev.com/62fdfa68da23bfa6920b919d6666a86f7388b039/chrome/browser/ui/views/tabs/tab_strip_unittest.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d42019b17546ac18febf6b08e38922819c1e2af5

commit d42019b17546ac18febf6b08e38922819c1e2af5
Author: Peter Kasting <pkasting@chromium.org>
Date: Tue Apr 24 19:41:49 2018

Initial work on MD Refresh new tab button position.

Does not implement padding in spec.

BUG= 822063 
TEST=none

Change-Id: Ifcbcb1f7b6e4385a6c0318624d95e6201b5d5a4a
Reviewed-on: https://chromium-review.googlesource.com/1024666
Reviewed-by: Allen Bauer <kylixrd@chromium.org>
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/master@{#553234}
[modify] https://crrev.com/d42019b17546ac18febf6b08e38922819c1e2af5/chrome/browser/ui/views/tabs/tab_strip.cc
[modify] https://crrev.com/d42019b17546ac18febf6b08e38922819c1e2af5/chrome/browser/ui/views/tabs/tab_strip.h
[modify] https://crrev.com/d42019b17546ac18febf6b08e38922819c1e2af5/chrome/browser/ui/views/tabs/tab_strip_layout.cc
[modify] https://crrev.com/d42019b17546ac18febf6b08e38922819c1e2af5/chrome/browser/ui/views/tabs/tab_strip_layout.h
[modify] https://crrev.com/d42019b17546ac18febf6b08e38922819c1e2af5/chrome/browser/ui/views/tabs/tab_strip_layout_unittest.cc

Stuff to do:

Position (incl. padding against other tabs)
Size
Hover/Pressed state
Ripple
Correct icon
Dynamic color against window frame (probably should be similar to caption buttons)
Fix incognito mode glitchiness
Handle "promo color" case

Not sure, if this is also an issue on other Platforms, but on macOS there is small glitch to see on the right side of the NewTab-Button.

Deleted: Bildschirmfoto 2018-04-25 um 18.42.26.png 29.6 KB

	Bildschirmfoto 2018-04-25 um 18.42.26.png 29.6 KB View Download

That's what "fix incognito mode glitchiness" means -- I already have a fix locally.

Refresh stuff is way too actively in development to report bugs against yet :)

Okay, thank you for the update and the information :-)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c248b124088bc04dbdbaf98d502a8c86e9975717

commit c248b124088bc04dbdbaf98d502a8c86e9975717
Author: Peter Kasting <pkasting@chromium.org>
Date: Thu Apr 26 00:31:29 2018

Compute NTB position dynamically from caption button position.

This makes Refresh use the trailing NTB for high-contrast RTL on Windows, where
we draw with the native frame and the caption buttons are on the right (i.e.
leading) edge.

BUG= 822063 
TEST=none

Change-Id: I92b58e1db4aef83d76e6e64abb93f9549db84067
Reviewed-on: https://chromium-review.googlesource.com/1029197
Reviewed-by: Bret Sepulveda <bsep@chromium.org>
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/master@{#553848}
[modify] https://crrev.com/c248b124088bc04dbdbaf98d502a8c86e9975717/chrome/browser/ui/views/frame/browser_non_client_frame_view.cc
[modify] https://crrev.com/c248b124088bc04dbdbaf98d502a8c86e9975717/chrome/browser/ui/views/frame/browser_non_client_frame_view.h
[modify] https://crrev.com/c248b124088bc04dbdbaf98d502a8c86e9975717/chrome/browser/ui/views/frame/browser_non_client_frame_view_mac.h
[modify] https://crrev.com/c248b124088bc04dbdbaf98d502a8c86e9975717/chrome/browser/ui/views/frame/browser_non_client_frame_view_mac.mm
[modify] https://crrev.com/c248b124088bc04dbdbaf98d502a8c86e9975717/chrome/browser/ui/views/frame/glass_browser_frame_view.cc
[modify] https://crrev.com/c248b124088bc04dbdbaf98d502a8c86e9975717/chrome/browser/ui/views/frame/glass_browser_frame_view.h
[modify] https://crrev.com/c248b124088bc04dbdbaf98d502a8c86e9975717/chrome/browser/ui/views/tabs/tab_strip.cc
[modify] https://crrev.com/c248b124088bc04dbdbaf98d502a8c86e9975717/chrome/browser/ui/views/tabs/tab_strip.h

Hi, this post is regarding the behavior of the ntb

Current behavior: pressing the ntb opens new tabs to the right of existing tabs/away from the ntb

expected behavior(?): pressing the ntb should open new tabs to the left of existing tabs/adjacent to the ntb.

Deleted: ntb_Behavior.mp4 1.4 MB

	ntb_Behavior.mp4 1.4 MB View Download

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1f1eed5b21ba5fc33b010fb31b24463185feb0b2

commit 1f1eed5b21ba5fc33b010fb31b24463185feb0b2
Author: Peter Kasting <pkasting@chromium.org>
Date: Thu Apr 26 18:14:39 2018

Fix a couple bugs with the New Tab Button in Refresh.

* Incognito mode should not try to draw part of an incognito indicator
* The bounding box y coordinate was wrong, which becomes noticeable with taller
  tabs

This also makes a couple of cleanup changes:

* Use "MD" type alias more pervasively
* Move a conditional inside another conditional because it's logically
  equivalent

BUG= 822063 
TEST=none

Change-Id: I93b016074dcce23178eee50227fcaabf57e07f9d
Reviewed-on: https://chromium-review.googlesource.com/1029263
Reviewed-by: Allen Bauer <kylixrd@chromium.org>
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/master@{#554084}
[modify] https://crrev.com/1f1eed5b21ba5fc33b010fb31b24463185feb0b2/chrome/browser/ui/views/tabs/new_tab_button.cc
[modify] https://crrev.com/1f1eed5b21ba5fc33b010fb31b24463185feb0b2/chrome/browser/ui/views/tabs/new_tab_button.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4201258320b95d3b599a4d1b899f89fb19baec7f

commit 4201258320b95d3b599a4d1b899f89fb19baec7f
Author: Peter Kasting <pkasting@chromium.org>
Date: Thu Apr 26 18:15:23 2018

Adjust new tab button position to more accurately match spec.

BUG= 822063 
TEST=none

Change-Id: I2220328551d8f34c464503c35e68b4e56ca3a6e6
Reviewed-on: https://chromium-review.googlesource.com/1029124
Reviewed-by: Allen Bauer <kylixrd@chromium.org>
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/master@{#554085}
[modify] https://crrev.com/4201258320b95d3b599a4d1b899f89fb19baec7f/chrome/browser/ui/layout_constants.cc
[modify] https://crrev.com/4201258320b95d3b599a4d1b899f89fb19baec7f/chrome/browser/ui/views/frame/browser_non_client_frame_view.cc

@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.

We have already seen a few Chrome Canary users complaining about the left position of new tab button in Chrome Help Forum.

https://productforums.google.com/forum/#!topic/chrome/XtmhlUhfosk

After having the new tab button to the right for 8 years or so, it's VERY hard and confusing to move the mouse all to the left. I even prefer the keyboard shortcut now, because I don't want to move it all to the left, then all to the right again.

On Mac on the other hand, the position is great.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e61d6110e6617bdc2899d20818b487eaf9f99a33

commit e61d6110e6617bdc2899d20818b487eaf9f99a33
Author: Peter Kasting <pkasting@chromium.org>
Date: Wed May 02 18:33:20 2018

Change TabStrip::GetMaxX() to GetTabsMaxX() so it works with TRAILING mode.

There were basically two callers of this function:
* GlassBrowserFrameView, which only cares about the new tab button position
  anyway, and thus can ask for it directly.
* BrowserNonClientFrameViewMus, which wants to know where the tabstrip's
  "client area" is.  Fix this by explicitly handling the "tab" and "new tab
  button" areas separately, so it won't matter if there's a "non-client" gap
  between them.  In theory, this frame should never be used with TRAILING mode,
  but with this change the TabStrip API can't be misused.

BUG= 822063 
TEST=none

Change-Id: Iaad98ce2485b2897ecffb6c5ec0a6bea5c218f7d
Reviewed-on: https://chromium-review.googlesource.com/1038789
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/master@{#555479}
[modify] https://crrev.com/e61d6110e6617bdc2899d20818b487eaf9f99a33/chrome/browser/ui/views/frame/browser_non_client_frame_view_mac.mm
[modify] https://crrev.com/e61d6110e6617bdc2899d20818b487eaf9f99a33/chrome/browser/ui/views/frame/browser_non_client_frame_view_mus.cc
[modify] https://crrev.com/e61d6110e6617bdc2899d20818b487eaf9f99a33/chrome/browser/ui/views/frame/glass_browser_frame_view.cc
[modify] https://crrev.com/e61d6110e6617bdc2899d20818b487eaf9f99a33/chrome/browser/ui/views/tabs/tab_strip.cc
[modify] https://crrev.com/e61d6110e6617bdc2899d20818b487eaf9f99a33/chrome/browser/ui/views/tabs/tab_strip.h
[modify] https://crrev.com/e61d6110e6617bdc2899d20818b487eaf9f99a33/chrome/browser/ui/views/tabs/tab_strip_unittest.cc

Triage: Load balancing to bsep@

bsep: Please reassess the EstimatedDays remaining for this issue. Thanks!

Keeping

Here's what remains on this bug beyond what's tracked elsewhere:

* Check and adjust spacing around NTB and tabstrip edges in all combos of position, OS, and RTL (I know this is wrong in some cases)
* Check icon; I used the touchable icon without changing it or checking how that aligned with the spec.

Also, add hover state to the NTB

Updating to P1 after discussion with bettes@ and remaining items list. Let's discuss if you feel otherwise, pk

The only thing the priority on this specific bug is covering is the stuff in comment 32, and that stuff is P2 rather than P1.  There are blocker bugs that are indeed P1.  :)

To clarify comment 32, my notes say:

"Fix padding pre-tabs in TRAILING & maybe AFTER_TABS mode
Fix Mac padding post-NTB, also Windows leading-edge-caption padding post-NTB"

Triage: Closing and cutting new bug for icon.

Um, can we not close this (multiple different open pieces of work + also serving as a metabug).

I'll try and split everything that's still on this bug into its own bugs and make this a pure metabug.

Filed bugs for both the above issues.  This is now a pure metabug.

Moving meta bugs to PM to make eng bandwidth more clear.

Apologies if this isn't the exact bug to post this, but the fixed new tab button placement should be at the very least an option on macOS and iPad. Safari for macOS and iPad have a fixed position new tab button, and when long time Safari users try Chrome, the moving target that is Chromes new tab button is enough to make them go back to Safari. 

Should I open a new issue # for that?

Certainly. You can assign it as a feature request and assign it to me!

@ markchang, just filed it :) https://bugs.chromium.org/p/chromium/issues/detail?id=905915