Fix window drawing after snap on Windows 10.

Fix window drawing after snap on Windows 10.

Sometimes during window snap the window will receive
WM_WINDOWPOSCHANGING with a new size, but not WM_WINDOWPOSCHANGED. This
causes Chrome to avoid drawing to the window because it thinks that
might cause the window contents to be stretched.

To prevent this post a windows message in the WM_WINDOWPOSCHANGING
handler, and if that message is received without a WM_WINDOWPOSCHANGED
then re-enable drawing.

BUG=562681
Committed: https://crrev.com/96d62242ba604ad301eb29dcb7e9b3e3c21f6aaf
Cr-Commit-Position: refs/heads/master@{#409096}

[jbauman, 2016-07-29 23:45:27]

The CQ bit was checked by jbauman@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-29 23:45:51]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[jbauman, 2016-07-29 23:53:40]

Description was changed from

==========
fix more


remove handlewindowsizechanged


redo format


started

BUG=
==========

to

==========
Fix window drawing after snap on Windows 10.

Sometimes during window snap the window will receive
WM_WINDOWPOSCHANGING with a new size, but not WM_WINDOWPOSCHANGED. This
causes Chrome to avoid drawing to the window because it thinks that
might cause the window contents to be stretched.

To prevent this post a windows message in the WM_WINDOWPOSCHANGING
handler, and if that message is received without a WM_WINDOWPOSCHANGED
then re-enable drawing.

BUG=562681
==========

[commit-bot: I haz the power, 2016-07-30 00:37:55]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-30 00:37:56]

Dry run: Try jobs failed on following builders:
  win8_chromium_gyp_rel on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win8_chromium_gyp...)

[jbauman, 2016-07-30 00:42:18]

The CQ bit was checked by jbauman@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-30 00:42:34]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-30 01:33:02]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-30 01:33:03]

Dry run: This issue passed the CQ dry run.

[jbauman, 2016-07-30 01:37:31]

jbauman@chromium.org changed reviewers:
+ sky@chromium.org

[sky, 2016-08-01 15:30:09]

Is it possible we're getting WM_WINDOWPOSCHANGED, but the client area hasn't
changed?

https://codereview.chromium.org/1811913007/diff/60001/ui/views/win/hwnd_messa...
File ui/views/win/hwnd_message_handler.cc (right):

https://codereview.chromium.org/1811913007/diff/60001/ui/views/win/hwnd_messa...
ui/views/win/hwnd_message_handler.cc:2333: 
SetMsgHanded(FALSE)?

[jbauman, 2016-08-01 19:10:54]

On 2016/08/01 15:30:09, sky wrote:
> Is it possible we're getting WM_WINDOWPOSCHANGED, but the client area hasn't
> changed?

No, we have code in OnWindowPosChanged to handle that. What happens is we get a
WM_WINDOWPOSCHANGING with a new size (and new client size), and sometimes we're
lucky enough to get a WM_WINDOWPOSCHANGED, but sometimes we don't get one at
all. I guess some piece of code inside windows changes the size back to what it
was previously, so it doesn't need to send out WM_WINDOWPOSCHANGED.
> 
>
https://codereview.chromium.org/1811913007/diff/60001/ui/views/win/hwnd_messa...
> File ui/views/win/hwnd_message_handler.cc (right):
> 
>
https://codereview.chromium.org/1811913007/diff/60001/ui/views/win/hwnd_messa...
> ui/views/win/hwnd_message_handler.cc:2333: 
> SetMsgHanded(FALSE)?

This is a completely made-up message, so I don't think we need to give it to
DefWindowProc or process it more.

[sky, 2016-08-01 23:00:04]

Ok, LGTM

[jbauman, 2016-08-01 23:10:07]

The CQ bit was checked by jbauman@chromium.org

[commit-bot: I haz the power, 2016-08-01 23:10:29]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-02 00:02:44]

Description was changed from

==========
Fix window drawing after snap on Windows 10.

Sometimes during window snap the window will receive
WM_WINDOWPOSCHANGING with a new size, but not WM_WINDOWPOSCHANGED. This
causes Chrome to avoid drawing to the window because it thinks that
might cause the window contents to be stretched.

To prevent this post a windows message in the WM_WINDOWPOSCHANGING
handler, and if that message is received without a WM_WINDOWPOSCHANGED
then re-enable drawing.

BUG=562681
==========

to

==========
Fix window drawing after snap on Windows 10.

Sometimes during window snap the window will receive
WM_WINDOWPOSCHANGING with a new size, but not WM_WINDOWPOSCHANGED. This
causes Chrome to avoid drawing to the window because it thinks that
might cause the window contents to be stretched.

To prevent this post a windows message in the WM_WINDOWPOSCHANGING
handler, and if that message is received without a WM_WINDOWPOSCHANGED
then re-enable drawing.

BUG=562681
==========

[commit-bot: I haz the power, 2016-08-02 00:02:47]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2016-08-02 00:07:03]

Description was changed from

==========
Fix window drawing after snap on Windows 10.

Sometimes during window snap the window will receive
WM_WINDOWPOSCHANGING with a new size, but not WM_WINDOWPOSCHANGED. This
causes Chrome to avoid drawing to the window because it thinks that
might cause the window contents to be stretched.

To prevent this post a windows message in the WM_WINDOWPOSCHANGING
handler, and if that message is received without a WM_WINDOWPOSCHANGED
then re-enable drawing.

BUG=562681
==========

to

==========
Fix window drawing after snap on Windows 10.

Sometimes during window snap the window will receive
WM_WINDOWPOSCHANGING with a new size, but not WM_WINDOWPOSCHANGED. This
causes Chrome to avoid drawing to the window because it thinks that
might cause the window contents to be stretched.

To prevent this post a windows message in the WM_WINDOWPOSCHANGING
handler, and if that message is received without a WM_WINDOWPOSCHANGED
then re-enable drawing.

BUG=562681

Committed: https://crrev.com/96d62242ba604ad301eb29dcb7e9b3e3c21f6aaf
Cr-Commit-Position: refs/heads/master@{#409096}
==========

[commit-bot: I haz the power, 2016-08-02 00:07:05]

Patchset 4 (id:??) landed as
https://crrev.com/96d62242ba604ad301eb29dcb7e9b3e3c21f6aaf
Cr-Commit-Position: refs/heads/master@{#409096}