WebVR: lock focus while presenting to presenting window

WebVR: lock focus while presenting to presenting window

This CL is kept intentionally simple for merging back to M59 to fix the regression, but hides some complexity.

This won't violate the assumption of one VRDisplay having a VSync provider at a time because VrDisplayImpl::GetVRVSyncProvider drops requests from displays that aren't presenting while presentation is active.

However, if a non-presenting VrDisplay actually gets focus while a different VrDisplay is presenting (possibly from directing the controller click to a different display) then that non-presenting VrDisplay will fail to get a VSync provider even after presentation ends because its focused state won't change and the original request will have failed. This means that a page with multiple VrDisplays will under certain degenerate cases fail to resume magic window mode after presenting until the focus changes again.

BUG=710863
Review-Url: https://codereview.chromium.org/2859533003
Cr-Original-Commit-Position: refs/heads/master@{#469804}
Review-Url: https://codereview.chromium.org/2881233002 .
Cr-Commit-Position: refs/branch-heads/3071@{#560}
Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}
Committed: https://chromium.googlesource.com/chromium/src/+/cb20474507616ce33723dfb02723e952703f3d88

[mthiesse, 2017-05-15 18:54:36]

Description was changed from

==========
WebVR: lock focus while presenting to presenting window

This CL is kept intentionally simple for merging back to M59 to fix the
regression, but hides some complexity.

This won't violate the assumption of one VRDisplay having a VSync provider at a
time because VrDisplayImpl::GetVRVSyncProvider drops requests from displays that
aren't presenting while presentation is active.

However, if a non-presenting VrDisplay actually gets focus while a different
VrDisplay is presenting (possibly from directing the controller click to a
different display) then that non-presenting VrDisplay will fail to get a VSync
provider even after presentation ends because its focused state won't change and
the original request will have failed. This means that a page with multiple
VrDisplays will under certain degenerate cases fail to resume magic window mode
after presenting until the focus changes again.

BUG=710863

Review-Url: https://codereview.chromium.org/2859533003
Cr-Commit-Position: refs/heads/master@{#469804}
(cherry picked from commit 89079d08e53122fc1921517942e259ec1e674d2d)
==========

to

==========
WebVR: lock focus while presenting to presenting window

This CL is kept intentionally simple for merging back to M59 to fix the
regression, but hides some complexity.

This won't violate the assumption of one VRDisplay having a VSync provider at a
time because VrDisplayImpl::GetVRVSyncProvider drops requests from displays that
aren't presenting while presentation is active.

However, if a non-presenting VrDisplay actually gets focus while a different
VrDisplay is presenting (possibly from directing the controller click to a
different display) then that non-presenting VrDisplay will fail to get a VSync
provider even after presentation ends because its focused state won't change and
the original request will have failed. This means that a page with multiple
VrDisplays will under certain degenerate cases fail to resume magic window mode
after presenting until the focus changes again.

BUG=710863

Review-Url: https://codereview.chromium.org/2859533003
Cr-Original-Commit-Position: refs/heads/master@{#469804}
Review-Url: https://codereview.chromium.org/2881233002 .
Cr-Commit-Position: refs/branch-heads/3071@{#560}
Cr-Branched-From:
a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}
Committed:
https://chromium.googlesource.com/chromium/src/+/cb20474507616ce33723dfb02723...
==========

[mthiesse, 2017-05-15 18:54:39]

Committed patchset #1 (id:1) manually as
cb20474507616ce33723dfb02723e952703f3d88.