New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 656001 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Nov 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Regression in Canary with handling of multi-monitors; Chrome disappears from screen

Reported by jakub.g....@gmail.com, Oct 14 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2890.0 Safari/537.36

Steps to reproduce the problem:
Pre-requisites:

- Windows 7, UI set to "classic" (Windows 2000-style)
- multiple physical monitors (my setup is: 3 monitors, identified "3", "2", "1" from left, with "2" being set as "main display")

1. open chrome canary on any monitor
2. click maximize
3. click key combo: `win + shift + arrow_(left|right)` which normally moves window between screens

!! nothing happens, it remains on the same screen

4. click the same combo several times (at least the no. of times equal to your number of physical monitors)
5. click (un)maximize

!! chrome canary disappears from screen (but it's still `alt-tab`bable)

After going back to Chrome via `alt-tab` and doing `win + shift + arrow_(left|right)` several times
you are able to see it back on the screen (though it took me a while to realize that).

What is the expected behavior?

What went wrong?
1. win-shift-arrows combos should let me move the window between the screen
2. the window should not disappear

Did this work before? N/A 

Chrome version: 56.0.2890.0  Channel: canary
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 23.0 r0

Chrome versions:

53.0.2785.143 m (stable) OK
54.0.2840.59 m (stable)  OK

!! 56.0.2889.0 canary (64-bit) KO
!! 56.0.2890.0 canary (64-bit) KO
 
FYI The monitors are all standard DPI so it's not a dupe of https://bugs.chromium.org/p/chromium/issues/detail?id=631212

However the monitors are differents res: 1680x1050, 1680x1050, 1920x1080
Labels: ReleaseBlock-Beta M-56 Needs-Bisect
Labels: TE-NeedsTriageFromMTV
We are unable to test this issue form Chrome @Hyd team. Requesting someone from MTV team to look in to this issue for further triaging.  

Comment 4 by chrah...@gmail.com, Oct 23 2016

I am having the same issue. I posted details here: http://superuser.com/questions/1138094/windows-key-shift-arrows-not-working-with-chrome.

Summary:
Cannot use Winkey+shift+[arrow] to change screens when Chrome is maximized. Restoring (un-maximizing) afterwards may move Chrome off-screen. Tested on Windows 10 v1607 build 14931.1000 with no change to settings or theme.
* Version 56.0.2896.3 dev (64-bit) - issue is present
* Version 56.0.2899.0 canary (64-bit) - issue is present
* Version 55.0.2883.21 beta-m (64-bit) - issue is NOT present

Comment 5 by chrah...@gmail.com, Nov 3 2016

Still occurring. Same version of Windows. Chrome versions:

* Version 56.0.2906.0 dev (64-bit)
* Version 56.0.2908.0 canary (64-bit)

Comment 6 by chrah...@gmail.com, Nov 3 2016

I went through the instructions [here](https://www.chromium.org/developers/bisect-builds-py) and narrowed it down:

PS C:\Users\Christopher\Desktop\chrome-fix> C:\Python27\python .\bisect-builds.py -a win64 -g 423768 -b 428890
Downloading list of known revisions... (use --use-local-cache to cache and re-use the list of revisions)
Downloading revision 426136...in_x64/425947/
Received 116264612 of 116264612 bytes, 100.00%
Bisecting range [423768 (good), 428882 (bad)].
Trying revision 426136...
Revision 426136 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
Downloading revision 425011...
Bisecting range [423768 (good), 426136 (bad)].
Trying revision 425011...
Revision 425011 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
Downloading revision 424177...
Bisecting range [423768 (good), 425011 (bad)].
Trying revision 424177...
Revision 424177 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
Downloading revision 424079...
Bisecting range [423768 (good), 424177 (bad)].
Trying revision 424079...
Revision 424079 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g
Downloading revision 424107...
Bisecting range [424079 (good), 424177 (bad)].
Trying revision 424107...
Revision 424107 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g
Downloading revision 424121...
Bisecting range [424107 (good), 424177 (bad)].
Trying revision 424121...
Revision 424121 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g
Downloading revision 424134...
Bisecting range [424121 (good), 424177 (bad)].
Trying revision 424134...
Revision 424134 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
Downloading revision 424126...
Bisecting range [424121 (good), 424134 (bad)].
Trying revision 424126...
Revision 424126 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
Downloading revision 424122...
Bisecting range [424121 (good), 424126 (bad)].
Trying revision 424122...
Revision 424122 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g
Downloading revision 424124...
Bisecting range [424122 (good), 424126 (bad)].
Trying revision 424124...
Revision 424124 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: r
Bisecting range [424122 (good), 424126 (bad)].
Trying revision 424124...
Revision 424124 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
You are probably looking for a change made after 424122 (known good), but no later than 424124 (first known bad
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/136a7131948b4adc886e8da7ddfac54c2ae8b1b8..ecf8bb9b85922db
69d579deb06ef58b

Comment 7 by chrah...@gmail.com, Nov 4 2016

Also tested and reproduced on Windows 10 Home Version: 1511 Build: 10586.633 with Chrome Canary 56.0.2909.0.
Cc: atimo...@yandex-team.ru sky@chromium.org
Labels: -Needs-Bisect has-Bisect
Owner: ananta@chromium.org
Status: Assigned (was: Unconfirmed)
As per the bisect provided in comment #6, suspecting the change and assigning it to the reviewer , as we are unable to find the author name in the CL.

@sky - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. 

Review-Url: https://codereview.chromium.org/2379063003

Thanks !

Comment 9 by sky@chromium.org, Nov 7 2016

Status: Fixed (was: Assigned)
hdodda you are right. Here's the two patches I reverted.

https://codereview.chromium.org/2484643003 and https://codereview.chromium.org/2482933002 are the reverts.

The same problem is also reproducible in current canary (after reverting my patches) for window in fullscreen mode: win-shift-arrows shortcuts aren't working.

Comment 11 by sky@chromium.org, Nov 8 2016

atimoxin@yandex-team.ru, can you clarify what you mean? I locally built yesterday, with your patches and saw the behavior this bug mentions. Then I reverted (locally) your patches and the shortcuts worked. This is why I reverted your two patches. Are you seeing otherwise?
Yes, @sky, you are right. Reverting my patches fixed bug for maximized window, but there is the same problem with window in fullscreen mode (not maximize mode).

Steps to reproduce:
1. open chrome
2. press F11 (switch to fullscreen)
3. press win-shift-left or win-shift-right shortcut
I suggested a second version of my patch that also fixes problem with shortcuts.
See crrev.com/2488993002.

Comment 14 by sky@chromium.org, Nov 9 2016

atimoxin, I can't repro that on stable. Are you sure that issue is new?
Hello, OP here.

I just checked 56.0.2918.0 canary (64-bit) and the problem seems to have been fixed - no longer reproducible for me.

Thanks,
Jakub
Regarding @comment 12, indeed in fullscreen mode (F11) there's a problem that shortcuts do not work, but it's the same in canary and stable (so it's not a regression), and moreover, shortcuts just do not work, but at least the window doesn't disappear from screen.
Project Member

Comment 17 by bugdroid1@chromium.org, Nov 15 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/306338a1ac90527e74f9604cd5b202d1cdf2cb63

commit 306338a1ac90527e74f9604cd5b202d1cdf2cb63
Author: atimoxin <atimoxin@yandex-team.ru>
Date: Tue Nov 15 10:02:57 2016

Restore maximized window position after detaching display.

Sometimes Windows incorrectly changes bounds of maximized windows after
attaching or detaching additional displays. In this case user can see
non-client area of the window (that should be hidden in normal case).

This workaround code restores window position if problem occurs and also
fixes problem with broken shortcuts for changing monitor (Win+Shift+Left
or Win+Shift+Right) for maximized and fullscreen mode, caused by
incorrect same monitor detection logic in OnWindowPosChanging() (see
 crbug.com/656001 ).

BUG= 651449 , 656001 

Review-Url: https://codereview.chromium.org/2488993002
Cr-Commit-Position: refs/heads/master@{#432156}

[modify] https://crrev.com/306338a1ac90527e74f9604cd5b202d1cdf2cb63/ui/views/win/hwnd_message_handler.cc

Sign in to add a comment