Controls offsets computed if either top or bottom are showing

cc/input/browser_controls_offset_manager.h

Index: cc/input/browser_controls_offset_manager.h
diff --git a/cc/input/browser_controls_offset_manager.h b/cc/input/browser_controls_offset_manager.h
index 401487c7aa2a2c37d65f980341bc2d95906fc090..aa35f52dbb87b9f1025a07d48362a847e90069db 100644
--- a/cc/input/browser_controls_offset_manager.h
+++ b/cc/input/browser_controls_offset_manager.h
@@ -95,8 +95,9 @@ class CC_EXPORT BrowserControlsOffsetManager
   // Accumulated scroll delta since last baseline reset
   float accumulated_scroll_delta_;
 
-  // Content offset when last baseline reset occurred
-  float baseline_content_offset_;
+  // Content offset when last baseline reset occurred.
+  float baseline_top_content_offset_;
+  float baseline_bottom_content_offset_;

[aelias_OOO_until_Jul13, 2016/11/04 04:35:09]

I tried Chrome Home flag locally and observed the bug that bottom position fixed
elements are overlapped by the bottom bar.  Please introduce a new method
ContentBottomOffset() symmetric to ContentTopOffset(), and apply the adjustment
to outer viewport BoundsDelta.

[mdjones, 2016/11/05 00:17:26]

The issue with the bottom bar overlapping is addressed in follow up CLs where I
pass the bottom controls information to ChromeFullscreenManager.

ContentBottomOffset is already in this class but I'm not sure how that
information helps more than simply having the bottom control offset would.

[aelias_OOO_until_Jul13, 2016/11/05 00:47:15]

This bug can't be fixed properly with a change to ChromeFullscreenManager,
because the code in the browser process runs asynchronously from the code that
positions and renders the fixed-position (in CC impl thread -- this is the
reason CC is involved in top-controls-hiding to begin with).  The only way to
get a pixel-perfect, jitter-free alignment of fixed-position element and the
URL-bar is via the approach I suggested.

You might be interested in this old slide deck about the URL-bar hiding design:
https://docs.google.com/presentation/d/1vHXijJqm011cfupbcNmQMI1HdA2lZ0ZjjirwR...

[mdjones, 2016/11/07 17:14:45]

I think what you are talking about may have already been done with the addition
of the bottom controls logic. I have added you as a reviewer on the follow up
patches to put this change into context. We can discuss further if there are
still issues.

[aelias_OOO_until_Jul13, 2016/11/08 00:37:46]

Yeah, OK, I see the appropriate code exists in CC in
https://cs.chromium.org/chromium/src/cc/trees/layer_tree_host_impl.cc?q=SetBo...
, and I suppose that if it I observed it doesn't work, it would be because the
Java side sends weird sizes down at the moment.

 
   // The percent height of the visible control such that it must be shown
   // when the user stops the scroll.