[Presentation API] Fix race condition in which state change is lost.

[Presentation API] Fix race condition in which state change is lost.

Currently there is a race condition between the PresentationConnection
being returned to PresentationDispatcher on a successful start() or
reconnect(), and PresentationDispatcher being notified by the browser
that the state change has become connected.

Although PresentationServiceImpl issues the state change strictly after
executing the callback returning the PresentationConnection, it appears
that they are using distinct independent message pipes, which do not
guarantee order of arrival between these two messages. If the state
change message arrives first, then it will be lost due to the
connection not yet registered with Blink at that point in time.

The fix here is to change state to connected in Blink, after the
PresentationConnection is registered.

This fix needs to be merged back to 57.

Additional test assertions will be in a followup patch.

BUG=684664
Review-Url: https://codereview.chromium.org/2653683006
Cr-Commit-Position: refs/heads/master@{#446465}
(cherry picked from commit 1ebdd16432860b90eaaeaba7042c2e9761b17ef7)

Review-Url: https://codereview.chromium.org/2661053002 .
Cr-Commit-Position: refs/branch-heads/2987@{#198}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}
Committed: https://chromium.googlesource.com/chromium/src/+/cdf4402738b87ca888eb12baa02d1b78bd396b4a

[imcheng, 2017-01-30 22:17:16]

Description was changed from

==========
[Presentation API] Fix race condition in which state change is lost.

Currently there is a race condition between the PresentationConnection
being returned to PresentationDispatcher on a successful start() or
reconnect(), and PresentationDispatcher being notified by the browser
that the state change has become connected.

Although PresentationServiceImpl issues the state change strictly after
executing the callback returning the PresentationConnection, it appears
that they are using distinct independent message pipes, which do not
guarantee order of arrival between these two messages. If the state
change message arrives first, then it will be lost due to the
connection not yet registered with Blink at that point in time.

The fix here is to change state to connected in Blink, after the
PresentationConnection is registered.

This fix needs to be merged back to 57.

Additional test assertions will be in a followup patch.

BUG=684664

Review-Url: https://codereview.chromium.org/2653683006
Cr-Commit-Position: refs/heads/master@{#446465}
(cherry picked from commit 1ebdd16432860b90eaaeaba7042c2e9761b17ef7)
==========

to

==========
[Presentation API] Fix race condition in which state change is lost.

Currently there is a race condition between the PresentationConnection
being returned to PresentationDispatcher on a successful start() or
reconnect(), and PresentationDispatcher being notified by the browser
that the state change has become connected.

Although PresentationServiceImpl issues the state change strictly after
executing the callback returning the PresentationConnection, it appears
that they are using distinct independent message pipes, which do not
guarantee order of arrival between these two messages. If the state
change message arrives first, then it will be lost due to the
connection not yet registered with Blink at that point in time.

The fix here is to change state to connected in Blink, after the
PresentationConnection is registered.

This fix needs to be merged back to 57.

Additional test assertions will be in a followup patch.

BUG=684664

Review-Url: https://codereview.chromium.org/2653683006
Cr-Commit-Position: refs/heads/master@{#446465}
(cherry picked from commit 1ebdd16432860b90eaaeaba7042c2e9761b17ef7)

Review-Url: https://codereview.chromium.org/2661053002 .
Cr-Commit-Position: refs/branch-heads/2987@{#198}
Cr-Branched-From:
ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}
Committed:
https://chromium.googlesource.com/chromium/src/+/cdf4402738b87ca888eb12baa02d...
==========

[imcheng, 2017-01-30 22:17:17]

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