Make compositor initialize top controls to be shown.

Make compositor initialize top controls to be shown.

Previously we were relying on the Browser to update to the showing state, but
this would sometimes lead to the top controls to flicker while navigating since
the compositor initialized them to hidden.

BUG=416944
Committed: https://crrev.com/0da0ba8bf287a3b5d8c731e97c5fa24e294847f5
Cr-Commit-Position: refs/heads/master@{#296757}

[bokan, 2014-09-24 21:08:17]

bokan@chromium.org changed reviewers:
+ aelias@chromium.org

[bokan, 2014-09-24 21:08:17]

Alexandre, PTAL. The LayerTreeImpl doesn't have the top controls height so it
can't init them them to show. We can't do it from the TopControlsManager
constructor since the callback to set the value on the LTI uses the
TopControlsManager pointer which is uninitialized while in the constructor. This
effectively starts the compositor with top_controls_height as the
top_controls_delta.

[aelias_OOO_until_Jul13, 2014-09-24 21:33:00]

The browser has the tools via "top controls constraints" to specify that the top
controls should be locked to shown.  It seems this isn't working correctly when
the compositor has just been created.  Showing them by default papers over this
issue since it's what we typically want on initialization, but it doesn't feel
like the right fix.

In content/renderer/render_view_impl_android.cc OnUpdateTopControlsState method,
I see a:
  // TODO(tedchoc): Investigate why messages are getting here before the
  //                compositor has been initialized.
and it just drops them on the floor in that case.  I wonder if caching that and
then calling UpdateTopControlsState in RenderWidget::initializeLayerTreeView()
(similar to what happens with viewport size) would fix this.

[aelias_OOO_until_Jul13, 2014-09-25 08:35:38]

Hmm, I notice that 39 branch point is tomorrow so lgtm to this as a quick fix
anyway.

[bokan, 2014-09-25 12:42:03]

On 2014/09/25 08:35:38, aelias wrote:
> Hmm, I notice that 39 branch point is tomorrow so lgtm to this as a quick fix
> anyway.

Thanks, I added a TODO and bug to track fixing the underlying issue.

[bokan, 2014-09-25 12:42:08]

The CQ bit was checked by bokan@chromium.org

[commit-bot: I haz the power, 2014-09-25 12:43:01]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/597393002/20001

[commit-bot: I haz the power, 2014-09-25 13:51:55]

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

[commit-bot: I haz the power, 2014-09-25 13:51:56]

Try jobs failed on following builders:
  mac_chromium_rel_swarming on tryserver.chromium.mac
(http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[bokan, 2014-09-25 18:04:36]

The CQ bit was checked by bokan@chromium.org

[commit-bot: I haz the power, 2014-09-25 18:06:06]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/597393002/40001

[commit-bot: I haz the power, 2014-09-25 19:17:32]

Committed patchset #3 (id:40001) as e6f820e38d283feaaf8c8b2f25c714a129cb1dbb

[commit-bot: I haz the power, 2014-09-25 19:18:27]

Patchset 3 (id:??) landed as
https://crrev.com/0da0ba8bf287a3b5d8c731e97c5fa24e294847f5
Cr-Commit-Position: refs/heads/master@{#296757}