Same issue on Version 69.0.3497.92 (Official Build) Arch Linux (64-bit).

Laptop with HiDPI screen (scaled to 150%).

Cannot replicate on 69.0.3497.92 (Official Build) Windows (64-bit)

That's intentional to have more drag zone.

I think the bug being reported is really that the visible hover region shouldn't include the drag zone.

There are a couple issues here.

First, to make sure windows are draggable from the top, we do extend the window drag region into the top few pixels of background tabs when background tab shapes are not normally visible.  That's intentional.  Arguably, once you hover the tab, we should consider it as having a visible shape and not do this extension; the effect would be that if you are over the very top of the tab, and then move down until it's hovered, and then back up to the previous position, it will still be hovered (though it wasn't initially).  I would consider that a legit P3 feature request; if you want this, feel free to file separately.

What I think is more core to this issue is the reference to maximized windows on Mac.  While "maximized" isn't a Mac concept, there is a fullscreen case where the window extends to the top of the screen, with a tabstrip visible.  On Windows in this case, we remove the drag handle region atop the tabs, and we also remove the extension into background tabs that the reporter here is complaining about.  This buys more content space and provides Fitts' Law benefits for tab targeting.  I think Mac should do the same.  The Fitts' Law stuff won't apply because the screen top triggers a menubar, but hiding the top drag region and avoiding the drag extension in this mode both seem like good changes.

->weili who owns the Mac frame here (I think) to implement.

OP or the other reporter, could you pls clarify one thing? iiuc, the problem is that the inactive tabs (aka background tabs) have a small drag area (~5px tall) at the top of the tab hover/highlighted area. This happens in normal browser window, it has nothing to do with whether your browser window is maximized or not, right?

I believe that creating such an drag area was intentional to give users more space to drag the window. Although updating the hover area to exclude the drag area might be a solution.

> OP or the other reporter, could you pls clarify one thing? iiuc, the problem is that the inactive tabs (aka background tabs) have a small drag area (~5px tall) at the top of the tab hover/highlighted area. This happens in normal browser window, it has nothing to do with whether your browser window is maximized or not, right?

Correct. In not-maximized and maximized windows on macOS you have a small drag area (~5px tall) at the top of the tab hover/highlighted area. (In macOS Fullscreen Mode the (~5px tall) area isn't there.)

> I believe that creating such an drag area was intentional to give users more space to drag the window. Although updating the hover area to exclude the drag area might be a solution.

I like the current behavior. I wouldn't change it.

Based on #7, I will leave the bug open for a while to collect more feedback before I mark it as 'won't fix'

Pardon me for not being explicitly clear in my original post. Here's an illustration along with an attempt at describing this better.

Also, could you please change the bug title to read "Hit area of non-focused tab is significantly shorter than its hover highlight and that of focused tab". Thanks


CURRENT BEHAVIOR
The targetable height of the focused tab == the visible height (34dp).
The user may click ANY pixel in this region to drag the tab.

The targetable height of any non-focused tab is 9dp shorter than implied by the height of a focused tab and the visible hover region of the non-focused tab itself. A primary purpose of a hover highlight
is to convey the targetable region of the button - Chrome’s tabs now violate this principle.

CONSEQUENCES OF THE 9DP FAUX HIT REGION
- a single click in the faux hit region to bring the tab forward will no-op
  - any mouse movement between mousedown and mouseup (common) moves the window
  - a quickly repeated click to correct this mistake toggles the window maximized/restored
- a drag gesture intended to reorder tabs will result in moving the window

Each of these consequences continues to happen to me repeatedly.

IF there's an assertion that this isn't a problem because there are no prior reports of this being an issue, I highly recommend introducing instrumentation to discover how frequently the consequences above are happening to users (e.g. how often does a user click within the 9px faux hit region then immediately afterward click lower on the actual hit region to focus that tab). The fact that nobody is reporting it doesn't mean nobody's experiencing it -- it could be that the effects are common but users aren't able to make heads or tails of what happened.

Deleted: Chrome Tabs Faux Hit Region.png 148 KB

	Chrome Tabs Faux Hit Region.png 148 KB View Download

Oops, that illustration had a blank background. Here's an updated one.

Deleted: Chrome Tabs Faux Hit Region.png 159 KB

	Chrome Tabs Faux Hit Region.png 159 KB View Download

@6: That's an extension of the top drag handle, so it's not present when that top handle is not present; that is, on Windows, it is not present in maximized mode.  See also comment 5.

@7: It's important to be clear.  The proposal here isn't to eliminate the drag handle extension when the window has a drag handle, which is I think what you're saying you "wouldn't change", but to eliminate the drag handle entirely (and its extension) in "maximized mode" as we do on other desktop platforms.

@9: You were very clear, but I bugmorphed, because we can't extend the window top handle big enough to be draggable without extending into the tabs, and it looks and feels even more bizarre if we e.g. shorten the tabs, but only the background ones, and only in non-maximized mode.  I'm not asserting it doesn't have problems or that nobody's reporting it, I'm asserting it's WontFix anyway because the solutions are worse.  The one thing we could potentially do is extend the tab's hit region to cover the full hovered area once the hover effect is visible, and as noted in comment 5, if you think that's worth doing, my request is "please file separately".

The reason I bugmorphed is that removing the top drag handle when the window is maximized should eliminate your problem in practice, and we can (and should) do that anyway).

BTW, the extension should not be 9 DIP -- it should extend to 1 DIP above the top of the separator, so 6 DIP.  If you're seeing something different (as you diagrammed), that's unexpected (and I'm not sure how it would happen); can you also file that separately, with a screencast demonstrating?

Also this is not P3

This does have Fitts' Law implications after all: it means that when dragging to reorder tabs in a maximized window, the drag area to stay within the window is no longer infinitely high.  Pulling a tab upwards will pull it out of the window.

Since pulling tabs out of a maximized window is an uncommon case compared to reordering them within that window, that's another reason we should fix this.  According to users (see e.g. https://www.reddit.com/r/chrome/comments/9i118s/omg_google_what_have_you_done_return_old_design/e6lmmv4 ) this is a regression.

***Mass UI Triage***
As per dev comments.