Controls offsets computed if either top or bottom are showing

cc/input/browser_controls_offset_manager.h

 // Copyright 2016 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef CC_INPUT_BROWSER_CONTROLS_OFFSET_MANAGER_H_
 #define CC_INPUT_BROWSER_CONTROLS_OFFSET_MANAGER_H_
 
 #include <memory>
 
 #include "base/macros.h"
@@ skipping 77 matching lines @@
   float animation_start_value_;
   base::TimeTicks animation_stop_time_;
   float animation_stop_value_;
   AnimationDirection animation_direction_;
 
   BrowserControlsState permitted_state_;
 
   // 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.
   float controls_show_threshold_;
 
   // The percent height of the visible control such that it must be hidden
   // when the user stops the scroll.
   float controls_hide_threshold_;
 
   bool pinch_gesture_active_;
 
   DISALLOW_COPY_AND_ASSIGN(BrowserControlsOffsetManager);
 };
 
 }  // namespace cc
 
 #endif  // CC_INPUT_BROWSER_CONTROLS_OFFSET_MANAGER_H_