New issue
Advanced search Search tips

Issue 830037 link

Starred by 3 users
Status: Assigned
Owner:
markchang@chromium.org
Cc:
weili@chromium.org
lgrey@chromium.org
ellyjo...@chromium.org
pkasting@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug-Regression
M-X



Sign in to add a comment

[MacViews-Browser] Regression: Last Tab in view disappears, when tabs are shrinked to the smallest size

Project Member Reported by meh...@chromium.org, Apr 6 2018 
Chrome Version: Canary 67.0.3390.0 
OS: macOS 10.12.6

What steps will reproduce the problem?
(1) Enable chrome://flags/#views-browser-windows
(2) Open a window
(3) Open so many tabs, so that the tabs shrink to the smallest state

What is the expected result?
There should not be a gap.

What happens instead?
The last tab disappears. A gap appears.

This is a recent regression in latest Canary with enabled MacViews flag.

A screencast is attached.

Maybe caused by one of the two CL's:

https://chromium-review.googlesource.com/996809 or https://chromium-review.googlesource.com/987528 ?
TapStripGap.mov
417 KB View Download

Comment 1 by meh...@chromium.org, Apr 6 2018

Summary: [MacViews-Browser] Regression: Last Tab in view disappears, when tabs are shrinked to the smallest size (was: [MacViews-Browser] Regression: Last Tab in view disappears, when tabs are in shrinked to the smallest size)

Comment 2 by meh...@chromium.org, Apr 6 2018

Description: Show this description

Comment 3 by lgrey@chromium.org, Apr 6 2018 

Looks like it's there but hidden because it would be overlapping the new tab button (screenshot attached of force showing it via UIDevTools).
Screen Shot 2018-04-06 at 5.26.31 PM.png
16.6 KB View Download

Comment 4 by lgrey@chromium.org, Apr 6 2018 

FWIW it seems like stable Cocoa sort of behaves the same way (no gap, but also no active tab, see screenshot).
Screen Shot 2018-04-06 at 5.30.26 PM.png
17.8 KB View Download

Comment 5 by ellyjo...@chromium.org, Apr 9 2018

Labels: M-68 MacViews-Browser Target-68
Owner: weili@chromium.org
Status: Assigned (was: Untriaged)
Tab overflow is generally super janky, but this shouldn't happen. Over to weili@ for M68 :)

Comment 6 by weili@chromium.org, Apr 12 2018

Status: Started (was: Assigned)
This doesn't seem to be an regression due to either CL mentioned by OP. I traced it to when we added #views-browser-windows. Will take a deeper look.

Comment 7 by weili@chromium.org, Apr 13 2018

Labels: Sprint-1

Comment 8 by weili@chromium.org, Apr 18 2018 

This is more involved than I thought. The described behavior has been on win/linux for a while. Fixing this means we need to implement Cocoa tab overflow strategy in views: the tab strip can extends a bit when active a tab during overflow. This maybe ok on Windows, but may not work on Linux as the new tab button is already very close to avatar before overflow.

Comment 9 by gov...@chromium.org, Apr 25 2018 

Pls mark the bug as fixed if CL is landed in trunk and nothing else is pending. Thank you.

Comment 10 by weili@chromium.org, Apr 25 2018

Labels: -M-68 -Target-68 -Sprint-1 Target-69 M-69
No, a new tab overflow design has been worked on, so it may not be worthwhile to implement any interim implementation for now. Let's revisit this in next release.

Comment 11 by robliao@chromium.org, Jun 28 2018

Status: Assigned (was: Started)

Comment 12 by robliao@chromium.org, Jul 12

Labels: -M-69 Group-Views_Regressions_from_Cocoa

Comment 13 by robliao@chromium.org, Jul 12

Labels: M-69

Comment 14 by robliao@chromium.org, Jul 26

Labels: -M-69 -Target-69 M-X
Owner: markchang@chromium.org
Dupe/WontFix this to the future tab overflow work.

Comment 15 by rbasuvula@chromium.org, Nov 23

Labels: Hotlist-DesktopUIChecked Hotlist-DesktopUIValid
***Mass UI Triage*** As per dev commens.
►

Sign in to add a comment