Issue 855277  has been merged into this issue.

How should the separators be handled in the case of stack tabs? If the tabstrip is drawing them all, that is just more that has to be taken into account. If the tab draw the divider, normal clipping should just handle it. While having the tabstrip draw all the dividers solves some issues, ISTM it's also introducing others. Yes, having the tabstrip draw all the dividers *may* be the right thing to do. I'd just like to travel a little further down the current road (tabs painting the divider) and see if that can handle the cases.

I think we get stacked tabs wrong already today.  Consider a tab that has a stack trailing off to its right side.  No dividers will be visible anywhere in this, because they're all on the left sides, which have all been overlapped by other tabs.

If we want tabs to draw dividers, the best route might be to have every tab draw dividers on both sides (maybe by defining them as part of the border path), and then overlap tabs by 1 additional DIP.  This would probably eliminate the need to hide dividers next to active/hovered tabs too?

If there is more overlap, will that not make where the top curves meet look a little odd, especially for higher scale factors?

What if the endcaps were an odd number of dips wide? If the endcap were 17dips, then the left edge would be at "9" and the right edge would be "right() - 9". I suspect this would toss the proverbial spanner into some of the stuff you're working on.

Top curves are only visible on the active and hovered tab, so I think it won't really be noticeable.  (Multiselection as well, but nobody actually multiselects tabs.)

For endcaps being bigger, I don't think it causes problems for anything I'm doing, but I don't have a clear picture in my head of what you're proposing w.r.t. how dividers align with curves, especially for active tabs.

The visible edges of the tabs would move in by 1 dip and the divider would paint just outside the edge of the tab rather right on the edge. That way, with a 1 dip overlap, the top curves would still look right. The dividers are painted on both ends, but one is clipped by the overlap.

The inactive tabs are visible for some themes though. So I think an overlap would be fairly visible in that instance.

Some more experimentation is warranted here. I want to actually see how this might work before committing (no pun intended) to any particular course.

Allen and I talked about this more.  Tentative plan:

* Do comment 9, including eliminating the idea of repainting tabs adjacent to hovered/active tabs, and the part of the alpha computation that takes the neighboring tab into account
* For the first tab (if NTB != LEADING) or the last tab (if NTB != TRAILING), set the alpha of the leading/trailing (respectively) separator based on the ratio of the left/right edge of the tab to the tab width.  For example (pseudocode):

  float leading_alpha = trailing_alpha = (existing hover-based computation);
  // Use the ideal width instead of current width when animating open; this ensures
  // that if we're hiding the trailing separator, a newly-opened last tab in the strip
  // won't start with a separator that quickly fades out as the tab finishes opening.
  const int tab_width = std::max(tab.width(), ideal_bounds(tab).width());
  if ((NTB == LEADING) && (index(tab) == 0)) {
    leading_alpha = float{std::min(tab.x() - TabStartX(), tab_width)} / tab_width;
  } else if ((NTB == TRAILING) && (index(tab) == num_tabs() - 1)) {
    const int ideal_x = ;
    trailing_alpha = float{std::min(TabStartX() + GetTabAreaWidth() - tab_width - tab.x(), tab_width)} / tab_width;
  }

This handles both hiding leading/trailing separators in the steady state, as well as fading them in/out as tabs animate during dragging.
* If NTB == TRAILING, have the tabstrip draw a fully-opaque separator right before the NTB.  (The NTB can't draw its own separator because the separator is outside the NTB's bounds.)

Let's engineer for just trailing here. DCHECK the other positions.

You mean AFTER_TABS.  (I got it wrong in my pseudocode in comment 13 too.)

I'd rather not add DCHECKs to the other positions (especially if we add flags to control this and thus the code is reachable), but if it takes extra time to support them we can try to avoid doing that work.

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

commit 0a83f2b07dc1691f182216c427511578071c9804
Author: Allen Bauer <kylixrd@chromium.org>
Date: Fri Jun 29 15:22:16 2018

Adjust the position of the tab separator based on NTB position.

Bug:  842798 
Change-Id: I2ccf920a119bece954ff037fed8e0e18cedadf25
Reviewed-on: https://chromium-review.googlesource.com/1113505
Commit-Queue: Allen Bauer <kylixrd@chromium.org>
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/master@{#571483}
[modify] https://crrev.com/0a83f2b07dc1691f182216c427511578071c9804/chrome/browser/ui/views/tabs/tab.cc
[modify] https://crrev.com/0a83f2b07dc1691f182216c427511578071c9804/chrome/browser/ui/views/tabs/tab.h
[modify] https://crrev.com/0a83f2b07dc1691f182216c427511578071c9804/chrome/browser/ui/views/tabs/tab_controller.h
[modify] https://crrev.com/0a83f2b07dc1691f182216c427511578071c9804/chrome/browser/ui/views/tabs/tab_strip.cc
[modify] https://crrev.com/0a83f2b07dc1691f182216c427511578071c9804/chrome/browser/ui/views/tabs/tab_strip.h
[modify] https://crrev.com/0a83f2b07dc1691f182216c427511578071c9804/chrome/browser/ui/views/tabs/tab_unittest.cc