Minimized snapped window may not restore to the snapped bounds |
|||
Issue descriptiontot chrome: Case a: (1) open a new browser (2) alt+[ to left snap it (3) minimize the browser (4) unminimize it we can see it is not restored to snapped bounds. Case b: However, for these following steps: (1) open a new browser (2) move the browser position a little bit (3) minimize the browser (4) unminimize it we can see it is restored to the correct bounds. Case c: Again, for these following steps: (1) open a new browser (2) move the browser position a little bit (3) alt+[ to left snap the window (3) minimize the browser (4) unminimize it we can see it is restored to the correct bounds. For case (a) bug, we can just treat left or right snap event as bounds_changed_by_user.
,
Feb 15 2017
My guess is that alt+[] shortcut wasn't considers as a user move, which is a bug.
,
Feb 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0402e8c9dd194fd74dce5eccf6b65cae62ae7847 commit 0402e8c9dd194fd74dce5eccf6b65cae62ae7847 Author: warx <warx@chromium.org> Date: Tue Feb 21 02:39:05 2017 cros: Fix minimized snapped window may not restore to the snapped bounds Changes: When new window is created, and snapped by shortcut, the minimizing/restoring will still be affected by window_positioner. This CL is to fix that. BUG= 692175 BUG=689764 TEST=test that the case(a) in crbug.com/692175 is fixed, test coverage is also added. Review-Url: https://codereview.chromium.org/2700433002 Cr-Commit-Position: refs/heads/master@{#451690} [modify] https://crrev.com/0402e8c9dd194fd74dce5eccf6b65cae62ae7847/ash/common/wm/default_state.cc [modify] https://crrev.com/0402e8c9dd194fd74dce5eccf6b65cae62ae7847/ash/wm/workspace_controller_unittest.cc
,
Feb 21 2017
,
Apr 4 2017
|
|||
►
Sign in to add a comment |
|||
Comment 1 by warx@chromium.org
, Feb 14 2017