New issue
Advanced search Search tips

Issue 730174 link

Starred by 7 users

Issue metadata

Status: Fixed
Owner:
Closed: Jul 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug

Blocked on:
issue 605219



Sign in to add a comment

High Sierra: Window traffic light control is mis-placed

Project Member Reported by rsesek@chromium.org, Jun 6 2017

Issue description

Chrome Version: 61.0.3122.0
OS: macOS 10.13 17A264c

What steps will reproduce the problem?
(1) Open Chrome
(2) Look at the window traffic lights
(3) Traffic lights are mis-aligned (should be center-aligned in the frame)
(4) Put Chrome in the background
(5) Traffic lights disappear altogether

What is the expected result?
Step 3 should have traffic lights aligned with the vertical center of the tabstrip. And in step 5, the traffic lights should be visible when Chrome is backgrounded.

What happens instead?

Please use labels and text to provide additional information.


For graphics-related bugs, please copy/paste the contents of the about:gpu
page at the end of this report.

 
Screen Shot 2017-06-06 at 4.50.16 PM.png
83.6 KB View Download
Screen Shot 2017-06-06 at 4.54.59 PM.png
62.0 KB View Download
Taking the window fullscreen and back seems to fix the vertical positioning, but the traffic light still disappears when the window isn't foreground.
Resizing by the corners fixed it for me too.  Issue 605219  could be at play here. "Reverting" r433658 could fix it (possibly  Issue 730679  as well), but it will bring back the autolayout woes.

Maybe there's something we can do that addresses the fullsize contentview thing in  Issue 605219  without opting in the browser window to autolayout.
Are you saying the root cause of the problem is us opting into autolayout because of r433658? As far as I know this change is not enabled because we haven't fixed all the autolayout problems (e.g. if I run Canary from the command line I still get "NSWindow warning: adding an unknown subview: <FullSizeContentView: 0x7fb7cfceea80>. Break on NSLog to debug"). Or am I confused about what you're saying?
 
I think the root cause is us replacing [[NSWindow contentView] superview] with our own NSView. That's what triggers the "unknown subview" warning.

 Issue 605219  implements a solution that avoids us having to replace [contentView superview] to draw the tab strip. However, in its current form, it causes the browser window to opt in to autolayout as a side-effect.

Comment 5 by lgrey@google.com, Jun 9 2017

Status: Available (was: Untriaged)

Comment 6 by rsesek@chromium.org, Jun 13 2017

Labels: ReleaseBlock-Stable M-61

Comment 7 by lgrey@chromium.org, Jun 19 2017

Probably same root cause:
Stoplights are showing up on the left in RTL, fixed by full-screen or dragging by the corners (but it has to be more than just a little).

Comment 8 by shrike@chromium.org, Jun 20 2017

Changing ShouldUseFullSizeContentView() to return true fixes the stoplight position problem.

Comment 9 by shrike@chromium.org, Jun 30 2017

Blockedon: 605219

Comment 10 by sdy@chromium.org, Jul 6 2017

Owner: sdy@chromium.org
Status: Started (was: Available)
A friendly reminder that M61 branch is coming soon on 07/20! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix ASAP to trunk. This way we branch M61 from a high quality trunk. Thank you.

Comment 12 by sdy@chromium.org, Jul 12 2017

Status: Fixed (was: Started)
 Issue 765926  has been merged into this issue.

Sign in to add a comment