Hide location bar on WebKit programmatic scroll.

cc/layer_tree_host.cc

Index: cc/layer_tree_host.cc
diff --git a/cc/layer_tree_host.cc b/cc/layer_tree_host.cc
index d120db00370db787c3fdafda604694f37e62482a..e891897f5f3c7c7c0b74cfb83b3bcc72f7f4e040 100644
--- a/cc/layer_tree_host.cc
+++ b/cc/layer_tree_host.cc
@@ -513,6 +513,13 @@ void LayerTreeHost::setPageScaleFactorAndLimits(float pageScaleFactor, float min
     setNeedsCommit();
 }
 
+void LayerTreeHost::hideTopControls()
+{
+   m_proxy->implThread()->postTask(

[John Knottenbelt, 2013/03/11 17:23:06]

Posting the task to the TopControlsManager in this way has the disadvantage that
the request to hide the top controls could arrive before the Commit() arising
from Javascript adjusting the offset of the scroll layer.

An alternative is to follow the same pattern as setPageScaleFactorAndLimits and
call setNeedsCommit. This could be picked up in
LayerTreeHost::finishCommitOnImplThread. This should be the same commit that
applies the change in scroll offset from Javascript.

What do you think? Should I implement this alternative flow?

[jamesr, 2013/03/14 19:38:34]

I believe it always will arrive before the Commit since both are run as tasks
posted from the main thread to the impl (compositor) thread and tasks are run in
FIFO order.
Do you need the top-controls hiding to be evaluated at the same time as the
scroll offset?  If so then yes, I think communicating this information along
with the commit is the right thing to do.  I'm not sure why the two need to be
evaluated together, though.

+       base::Bind(&TopControlsManager::HideTopControls,
+                   m_topControlsManagerWeakPtr));
+}
+
 void LayerTreeHost::setVisible(bool visible)
 {
     if (m_visible == visible)