Issue metadata
Sign in to add a comment
|
Regression : Unable to resize the browser to its minimum level after exiting from full screen mode.
Reported by
yfulgaon...@etouch.net,
Nov 11 2016
|
||||||||||||||||||||||
Issue descriptionChrome Version : 56.0.2916.0 (Official Build) bee9d25dd206a08d4b9b1bd86900cc354d8bb4e0-refs/heads/master@{#431463} 64-bit OS : Mac(10.11.6, 10.12.1, 10.12) Precondition : Please resize the browser window to fit screen. What steps will reproduce the problem? 1. Launch chrome and click on ‘full screen’ button in top left corner (browser enters full screen mode) 2. Again click on ‘full screen’ button (browser exits from full screen mode). 3. Now try to resize browser by dragging inwards from bottom right corner and observe. Actual : Unable to resize the browser to its minimum level after exiting from full screen mode. Expected : User should be able to resize the browser to its minimum level after exiting from full screen mode. This is a regression issue broken in ‘M-56’, below is the Manual Regression range and will soon update bisect info. Good Build : 56.0.2886.0 Bad Build : 56.0.2888.0 Note : This is Mac specific issue and the same is working fine in Windows & Linux OS.
,
Nov 12 2016
,
Nov 12 2016
I can reproduce it with latest Canary 56.0.2916.0 on OSX 10.11.6. The regression is: https://chromium.googlesource.com/chromium/src/+log/cedb9638610256a293d802876f04d05f11249776..41c5c138b099891457c2e0cb965b8f24dacc403e May be caused by https://codereview.chromium.org/2404783002 ? eugenebut@ Could you please check, if your change is causing this issue? Attached a screencast. Thanks in advance.
,
Nov 12 2016
,
Nov 13 2016
Trent, could you please take a look.
,
Nov 14 2016
Yeah this is pretty bad
,
Nov 14 2016
So I think this is an autolayout contraint going wonky. And it's related to the downloads bar. E.g. downloading a file to cause the downloads bar to get attached makes the window resizable beyond the minimum again. However, before the downloads bar is initialized, there's a layout constraint there which seem to be violated when resizing the window to be small, after going fullscreen. See attached diagnostics.
,
Nov 14 2016
,
Nov 15 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d8b183ffcfbb18293f623615017bc2e25b023906 commit d8b183ffcfbb18293f623615017bc2e25b023906 Author: tapted <tapted@chromium.org> Date: Tue Nov 15 00:41:53 2016 Mac: Always layout the Download Shelf, even if it has zero height. Even when the download shelf has zero height, Cocoa autolayout can change its width. It does this when going fullscreen. However, not when exiting fullscreen. If the download shelf is visible (i.e. has non-zero height), then -[BrowserWindowController applyLayout:] does the layout instead. However, currently that layout is skipped if the download shelf is hidden. This can leave the download shelf with a stale width that influences the Cocoa autolayout applied when the browser window is user-resized. This, in turn, can result in the browser window refusing to violate a constraint that would break when the browser window is resized to be small. To fix, always set the download shelf frame, even if it has zero height. This ensures the width is valid, even when hidden. BUG= 664477 TEST=On Mac (10.11 or 10.12) Open a new browser window (without a download shelf). Resize the window to be "large", then make it fullscreen (e.g. Cmd+Ctrl+f). Exit fullscreen (e.g. Cmd+Ctrl+f), then resize the window again to try to make it "small". Ensure the width can be made small as normal. Review-Url: https://codereview.chromium.org/2502533002 Cr-Commit-Position: refs/heads/master@{#432024} [modify] https://crrev.com/d8b183ffcfbb18293f623615017bc2e25b023906/chrome/browser/ui/cocoa/browser_window_controller_private.mm
,
Nov 15 2016
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by hdodda@chromium.org
, Nov 11 20162.1 MB
2.1 MB View Download