Currently, browser controls animate purely based on the change in the height, not on the change in minHeight. This works fine when that change is the same, but causes issues if the minHeight has been changed by a different value than the height has. This is mitigated by "stepping up" or "down" the starting min height offset such that the effective change is the same for both the height and minHeight.
This is specifically to address new situations with the addition of the BottomControlsStacker and the Edge-to-Edge bottom chin, a new bottom controls layer. This bottom chin can usually scroll off, but it should avoid doing so when the Read Aloud mini player is visible (or, more generally, when there's another non-scrolling component present in the bottom controls) so that the chin can exist as bottom padding. This means that updates to the browser controls where the change in height and min height differ, which previously didn't happen, are going to be reasonably common.
Bug: 359652364
Change-Id: Ib9f5ba66cf88a9667018eddbfb440c5bf36b84dc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5809844
Reviewed-by: Matthew Jones <mdjones@chromium.org>
Commit-Queue: Charles Hager <clhager@google.com>
Reviewed-by: Steve Kobes <skobes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1347654}
If chrome starts an animation to show browser controls that has
either (a) not completed before a user gesture scroll starts, or
(b) starts during the user gesture scroll, then restart the
animation after the scroll completes. This makes it unambiguous
to the user that the controls can be present, since the scroll
will cancel the animation otherwise. We don't want a small
scroll, which is easy to generate accidentally, to have the large
effect of preventing the browser controls from becoming visible.
For simplicity, this CL doesn't try to differentiate a small
scroll from any other; any scroll that overlaps with an animation
to show the browser controls results in the controls becoming
visible when the scroll completes.
Bug: 1341541
Change-Id: I58950b78bd02cb84989290a45cf5f67626508c61
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4136461
Reviewed-by: David Bokan <bokan@chromium.org>
Commit-Queue: Frank Liberato <liberato@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1089760}
As discussed in https://bit.ly/3qtrn9s we want to use gfx::PointF for
scroll offset (out of blink renderer) and gfx::Vector2dF for scroll
delta, instead of gfx::Vector2dF for both, for the following purposes:
1. To make it easier to do the correct thing: passing blink scroll
position (currently using FloatPoint, will be changed to gfx::PointF)
to out-of-blink scroll offset (and vice versa); and to make it
difficult to do the incorrect thing: passing blink scroll offset [1]
to out-of-blink scroll offset. Without this CL, the incorrect thing
would be easier to do than the correct thing because of the data
type mismatches.
2. We can better distinguish scroll offset and scroll delta with
different data types.
3. Make it consistent to use gfx::Point[F] for absolute scroll offsets
throughout Chromium.
[1] See third_party/blink/core/layout/README.md for detailed explanation
for of scroll position and scroll offset in blink renderer.
Bug: 738465
Change-Id: Ic9ac9658b8f3154514608ef4039780d0f20883bb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3267944
Reviewed-by: Bo <boliu@chromium.org>
Reviewed-by: Steve Kobes <skobes@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Kentaro Hara <haraken@chromium.org>
Owners-Override: Kentaro Hara <haraken@chromium.org>
Cr-Commit-Position: refs/heads/main@{#941498}
If the top controls height and min-height changed with animation and
the change in height was bigger than the min-height, the top controls
min-height offset would get an invalid value that is greater than the
min-height itself.
This CL clamps the min-height offset to the animation [start, end] range
to fix the issue.
Bug: 1184902
Change-Id: I0f5ea7fef6cd90ef18d48d476e5a21d5acca07c7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2783357
Reviewed-by: Matt Jones <mdjones@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Commit-Queue: Sinan Sahin <sinansahin@google.com>
Cr-Commit-Position: refs/heads/master@{#867748}
This is a reland of b207aafb60
The original version of this CL would disable animations when destroying
BrowserControlsContainerView, including the bottom view, which asserted
that setAnimationsEnabled wasn't called on it. This would fail depending
on whether or not weblayer's teardown finished before the test finished.
Original change's description:
> [WebLayer] Let the embedder animate top controls in/out.
>
> This CL adds an "animate" flag to Browser.setTopView that allows the
> embedder to tell WebLayer to animate the top view off the screen when
> setting it to null, or to animate it down from the top when setting it
> to a non-null value.
>
> The animation off the screen is achieved by removing the View from the
> view tree, but keeping the bitmap layer in place, hiding the top
> controls, and then deleting the layer after the animation is complete.
>
> Bug: 1108956
> Change-Id: Idb9bce6c2633ef6d1d369ccb2741ae6fd1fe43a2
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2335800
> Reviewed-by: Scott Violet <sky@chromium.org>
> Reviewed-by: Khushal <khushalsagar@chromium.org>
> Reviewed-by: Bo <boliu@chromium.org>
> Reviewed-by: David Bokan <bokan@chromium.org>
> Commit-Queue: Robbie McElrath <rmcelrath@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#797826}
Bug: 1108956
Change-Id: I79050b417cf68714061e515cf3ec6433dbbfac6c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2357369
Commit-Queue: Robbie McElrath <rmcelrath@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Reviewed-by: Khushal <khushalsagar@chromium.org>
Reviewed-by: Sinan Sahin <sinansahin@google.com>
Reviewed-by: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#798992}
This CL renames the ShouldPinControlsToContentTop field, which I landed
in crrev.com/c/2284138, to OnlyExpandControlsAtPageTop. The term
'pin' had caused some confusion, as had the phrase 'content top', since
that could be interpreted as either the viewport top, or the top of the
page itself. I had considered OnlyExpandControlsAtTop, but 'controls
at top' could be interpreted as 'top controls'.
Bug: 1069498
Change-Id: Iaff131ae1379113958cdfb4803e902e08a1949ae
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2336013
Commit-Queue: Robbie McElrath <rmcelrath@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#798905}
This CL adds an "animate" flag to Browser.setTopView that allows the
embedder to tell WebLayer to animate the top view off the screen when
setting it to null, or to animate it down from the top when setting it
to a non-null value.
The animation off the screen is achieved by removing the View from the
view tree, but keeping the bitmap layer in place, hiding the top
controls, and then deleting the layer after the animation is complete.
Bug: 1108956
Change-Id: Idb9bce6c2633ef6d1d369ccb2741ae6fd1fe43a2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2335800
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Khushal <khushalsagar@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Commit-Queue: Robbie McElrath <rmcelrath@chromium.org>
Cr-Commit-Position: refs/heads/master@{#797826}
This CL defines WebContentsDelegate::ShouldPinTopControlsToContentTop(),
which embedders can use to tell BrowserControlsOffsetManager to only
show the top browser controls if the page is scrolled to the top.
WebLayer's Browser#setTopView pinToContentTop parameter is hooked up to
this new method.
Bug: 1069498
Change-Id: I7a19656c0ee3219936c3279bfb89591b1f3abb56
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2284138
Commit-Queue: Robbie McElrath <rmcelrath@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#790985}
When the browser controls params change, we set the bottom shown ratio
to 0 if the new bottom controls height is 0. This causes us to hit a
DCHECK in SetupAnimation() because we don't early out from
UpdateBrowserControlsState() thinking the ratios need animating.
This CL keeps updating the shown ratio even if the controls height is 0.
We already keep the bottom controls shown ratio "alive" even if the
height is 0 during scrolls and show/hide animations.
Bug: 1094529
Change-Id: Ic8fad2fc0c44ad1b879efdd22e93e2fcd5d356c5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2248931
Reviewed-by: Khushal <khushalsagar@chromium.org>
Reviewed-by: Theresa <twellington@chromium.org>
Reviewed-by: Matthew Jones <mdjones@chromium.org>
Commit-Queue: Sinan Sahin <sinansahin@google.com>
Cr-Commit-Position: refs/heads/master@{#780988}
CHECK, CHECK_EQ etc., and NOTREACHED/NOTIMPLEMENTED have moved
to the much smaller headers check.h, check_op.h, and notreached.h,
respectively.
This CL updates .cc files to use those headers instead when
possible, with the purpose of saving compile time.
(Split out from https://crrev.com/c/2164525 which also has
notes on how the change was generated.)
Bug: 1031540
Change-Id: I0181b660daff212d6bbd777da7f241b62fa10b00
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2164890
Auto-Submit: Hans Wennborg <hans@chromium.org>
Reviewed-by: vmpstr <vmpstr@chromium.org>
Commit-Queue: Hans Wennborg <hans@chromium.org>
Cr-Commit-Position: refs/heads/master@{#762834}
With this CL, changes to browser controls height and/or min-heights are
animated by cc::BrowserControlsOffsetManager. When the heights change,
BCOM will get a call and decide how to animate the browser controls
shown ratios.
The next step will be to position the status indicator's cc layer
during the height change animation using the ratios (or offsets to be
more accurate).
Bug: 989148
Change-Id: I65abec486bb0026452bb498f237af099142f225e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1960783
Reviewed-by: Matthew Jones <mdjones@chromium.org>
Reviewed-by: Ted Choc <tedchoc@chromium.org>
Reviewed-by: Theresa <twellington@chromium.org>
Reviewed-by: Khushal <khushalsagar@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Commit-Queue: Sinan Sahin <sinansahin@google.com>
Cr-Commit-Position: refs/heads/master@{#731005}
Right now, top and bottom browser controls can have a shown ratio
between 0 and 1. This CL adds the ability to set a minimum height for
either. Once set, the browser controls will not completely scroll off
the screen, but will stop scrolling once the controls' visible height
reaches a min height. A minimum shown ratio is calculated in
blink::BrowserControls or cc::BrowserControlsOffsetManager using the
min-height. This minimum shown ratio is then used to limit the shown
ratio of the browser controls when scrolling.
This particular CL adds the plumbing to get the minimum height from
Java to (blink and cc) browser controls. Apart from the height and min
heights, an "animate" bit is also sent from Java to native side. If
animate is true, cc::BCOM will animate the changes to the height and/or
min height of the browser controls. The actual animation logic will be
added in an upcoming CL.
Having a minimum height will give us an area to put a persistent
Android view above the omnibox that won't scroll off.
Bug: 989148
Change-Id: I123bcd2a089e20191d5416158eb8a4fe1449d6ef
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1918262
Reviewed-by: Alex Gough <ajgo@chromium.org>
Reviewed-by: Khushal <khushalsagar@chromium.org>
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Reviewed-by: Jinsuk Kim <jinsukkim@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Commit-Queue: Sinan Sahin <sinansahin@google.com>
Cr-Commit-Position: refs/heads/master@{#722140}
This CL adds a helper Animation class to browser_controls_offset_manager and separates the top and bottom controls by giving them Animation instances. Currently, the top and bottom controls still animate together, but an upcoming CL will make use of the separated animations.
Bug: 989148
Change-Id: I8d7062073cfe300a52d9fa643e47982ef618b811
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1862269
Commit-Queue: Sinan Sahin <sinansahin@google.com>
Reviewed-by: Matthew Jones <mdjones@chromium.org>
Reviewed-by: Khushal <khushalsagar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#710565}
The linked bug is a result of the fact that we send and handle browser
controls state updates on both the main and compositor threads. When a
non-animated hide is followed by a animated hide, we start an animation
on the compositor thread but immediately hide the top controls on the
main thread. When we commit the browser controls delta, the controls
hide but the animation continues to play so the next frame re-shows the
controls. Additional updates may stop the animation so we'd see the
controls in a half-way hidden state.
Currently, UpdateBrowserControlsState sends animated commands to be
handled by CC (since Blink doesn't know how to animate), but because of
https://crbug.com/754346, non-animated commands are sent to Blink. When
the browser process sends a series of interweaved commands to the render
this leads the the clamping bug discussed above.
This CL fixes this issue by making the compositor-side the real source-
of-truth and pushing the changes to Blink. Both CC and Blink must be
made aware of the browser controls constraints, since scrolls may be
handled by either. However, we now always inform CC first and let it
push the differences to Blink. This happens as part of
ApplyViewportChanges during a commit.
Reland Note: The original patch broke MSAN as it forgot to initialize
ScrollAndScaleSet::browser_controls_constraint_changed. This CL fixes
that issue.
TBR=enne@chromium.org,chrishtr@chromium.org,alexmos@chromium.org
Bug: 861618
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I77964a893a9e376ceb29a69c6bef8b699801ed82
Reviewed-on: https://chromium-review.googlesource.com/c/1283249
Reviewed-by: David Bokan <bokan@chromium.org>
Commit-Queue: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#599963}
This reverts commit 2bd206ee01.
Reason for revert: This patch may be the culprit behind cc_unittest TreeSynchronizerTest.SynchronizeScrollTreeScrollOffsetMap failing on Linux ChromiumOS MSan Tests [20 out of the last 20 builds have failed] and Linux MSan Tests [21 out of the last 21 builds have failed]. Reverting to try and fix.
Original change's description:
> BrowserControlsState updates CC and commits to Blink
>
> The linked bug is a result of the fact that we send and handle browser
> controls state updates on both the main and compositor threads. When a
> non-animated hide is followed by a animated hide, we start an animation
> on the compositor thread but immediately hide the top controls on the
> main thread. When we commit the browser controls delta, the controls
> hide but the animation continues to play so the next frame re-shows the
> controls. Additional updates may stop the animation so we'd see the
> controls in a half-way hidden state.
>
> Currently, UpdateBrowserControlsState sends animated commands to be
> handled by CC (since Blink doesn't know how to animate), but because of
> https://crbug.com/754346, non-animated commands are sent to Blink. When
> the browser process sends a series of interweaved commands to the render
> this leads the the clamping bug discussed above.
>
> This CL fixes this issue by making the compositor-side the real source-
> of-truth and pushing the changes to Blink. Both CC and Blink must be
> made aware of the browser controls constraints, since scrolls may be
> handled by either. However, we now always inform CC first and let it
> push the differences to Blink. This happens as part of
> ApplyViewportChanges during a commit.
>
> Bug: 861618
> Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
> Change-Id: I6cb6a6480804fff05e6aee65166bf0d303fb677d
> Reviewed-on: https://chromium-review.googlesource.com/c/1205797
> Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
> Reviewed-by: enne <enne@chromium.org>
> Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
> Commit-Queue: David Bokan <bokan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#599523}
TBR=bokan@chromium.org,chrishtr@chromium.org,enne@chromium.org,alexmos@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: 861618
Change-Id: I6738ee1fb616e2b06b5a466546a8f47bcaeb7d79
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/c/1278460
Reviewed-by: Patti <patricialor@chromium.org>
Commit-Queue: Patti <patricialor@chromium.org>
Cr-Commit-Position: refs/heads/master@{#599556}
The linked bug is a result of the fact that we send and handle browser
controls state updates on both the main and compositor threads. When a
non-animated hide is followed by a animated hide, we start an animation
on the compositor thread but immediately hide the top controls on the
main thread. When we commit the browser controls delta, the controls
hide but the animation continues to play so the next frame re-shows the
controls. Additional updates may stop the animation so we'd see the
controls in a half-way hidden state.
Currently, UpdateBrowserControlsState sends animated commands to be
handled by CC (since Blink doesn't know how to animate), but because of
https://crbug.com/754346, non-animated commands are sent to Blink. When
the browser process sends a series of interweaved commands to the render
this leads the the clamping bug discussed above.
This CL fixes this issue by making the compositor-side the real source-
of-truth and pushing the changes to Blink. Both CC and Blink must be
made aware of the browser controls constraints, since scrolls may be
handled by either. However, we now always inform CC first and let it
push the differences to Blink. This happens as part of
ApplyViewportChanges during a commit.
Bug: 861618
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I6cb6a6480804fff05e6aee65166bf0d303fb677d
Reviewed-on: https://chromium-review.googlesource.com/c/1205797
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Reviewed-by: enne <enne@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#599523}
This patch adds methods to SimCompositor to allow ticking some basic
impl-side animations. In particular, this is used in
https://crrev.com/c/1205797 to play a browser controls animation from
impl-side code.
Despite the fact that SimCompositor supports only single-threaded mode,
an impl animation can still be initiated. Though there is no "impl
thread" on which the animation can be serviced, we can tick it by
producing main frames using BeginFrame (the commit calls
LayerTreeHostImpl::Animate). BeginFrame checks that a new frame is
actually needed so this adds a plumbing to make this check work with
changes coming from the "impl-side".
Another wrinkle is that the browser controls animation was based on
TimeTicks::Now; the start and end times are set from Now() and the
incoming frame_time is used to interpolate a value between the two. This
CL updates BrowserControlsOffsetManager to get the start time from the
first frame time, allowing tests to use a mock clock. This works more
like scrollbar and other animations but requires fixing tests that
assumed the first tick would produce delta.
We also add plumbing to pass viewport changes to Blink to allow the impl
side changes to propagate to Blink through ApplyViewportChanges, since
things can now change outside of the "main thread" side.
The ScrollSnapTest change was necessary in a previous iteration of this
CL when I made a change to the last_frame_time in SimCompositor. Though
that change was undone in favor of fixing the animation start time in
BrowserControlsOffsetManager, the changes in ScrollSnapTest are still
desirable since they make dispatched events use timestamps that
explicitly correspond to the frame times we use in BeginFrame.
Bug: 861618
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I069268d1b3ae25003f62f3e9b9c2ad54245e402c
Reviewed-on: https://chromium-review.googlesource.com/c/1270344
Reviewed-by: danakj <danakj@chromium.org>
Commit-Queue: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#599232}
Replace and remove Web types from the WebLayerTreeView interface. Use
the cc and gfx types, that they were converted to in LayerTreeView,
directly.
R=haraken@chromium.org
TBR=piman
Bug: 838693
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_layout_tests_layout_ng;luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I6a9cf8bf14721f7b9d8fd0448907c801c7131746
Reviewed-on: https://chromium-review.googlesource.com/1128188
Commit-Queue: danakj <danakj@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#573796}
Similar to https://crrev.com/c/1079608, this CL replaces uses of the
viewport scroll layers with the equivalent scroll node from the property
tree. This prepares for enabling blink-generated-property-trees since we
wont create the viewport scroll layers in that case, only the property
tree nodes.
This patch makes call sites use an accessor method which grabs the
scroll node from the viewport layer. A follow up patch will change this
helper to use the property tree directly if we're in BGPT mode. Some
more involved uses of the viewport layers remain and will have to be
fixed in future CLs but this is enough to enable basic scale-and-scroll
funcionality.
Note: while we did convert some uses of the outer viewport layer here,
we're mainly concerned with the inner viewport. That's because the
outer viewport is a scroller that generates content (like other
scrollers) and will continue to create and use a layer in BGPT. The
inner viewport layer is conceptual and will thus not generate a layer.
This CL should have no functional changes.
Bug: 836910
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ifa83fed2fa9b1847729ffafe75846da08e204237
Reviewed-on: https://chromium-review.googlesource.com/1085639
Commit-Queue: David Bokan <bokan@chromium.org>
Reviewed-by: Tien-Ren Chen <trchen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#566393}
It no longer defines base::MakeUnique, so it should only be included
where base::WrapUnique is used.
Generated by:
for x in `git grep -l '#include "base/memory/ptr_util.h"' cc gpu`; do \
grep -q WrapUnique "$x" || sed -i -e \
'/^#include "base\/memory\/ptr_util\.h"$/d' "$x"; done
Bug: 755727
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I5e19711f9932ba6ef30c8361fd62387bfab507ac
Reviewed-on: https://chromium-review.googlesource.com/1007894
Reviewed-by: Antoine Labour <piman@chromium.org>
Commit-Queue: Jeremy Roman <jbroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550245}
When the toolbar animates to hide when entering fullscreen, it can
cause a very janky transition. Part of the inline page is scrolled
into view at the bottom during the animation. Plus, the fullscreen
content slides up with the toolbar.
This CL turns off the animation, and instead just hides the toolbar
immediately. This greatly improves the transition.
Unfortunately, it also uncovered a bug: sometimes, the toolbar
would remain visible in fullscreen mode if the renderer is pushing
frames to the cc impl tree during the fs transition. See the
bug for more details.
To get around this, the impl thread no longer forces the ratio to
zero if it's not being animated. It is updated when the next
pending tree is pushed, to avoid the double update (and the
subsequent double-clamp that results in it being shown).
Bug: 754346
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I269e2ead0b81db6635231640b28b7aa30ff950e1
Reviewed-on: https://chromium-review.googlesource.com/617922
Reviewed-by: Alexandre Elias <aelias@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Reviewed-by: Ted Choc <tedchoc@chromium.org>
Reviewed-by: Matthew Jones <mdjones@chromium.org>
Commit-Queue: Frank Liberato <liberato@chromium.org>
Cr-Commit-Position: refs/heads/master@{#498111}
Includes of base/memory/ptr_util.h are expected to be rewritten
in a followup CL, to reduce conflicts.
Bug: 755727
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I33b9866476d8df3a4f60ad7277ff1b43c1472aaf
Reviewed-on: https://chromium-review.googlesource.com/627171
Commit-Queue: Jeremy Roman <jbroman@chromium.org>
Reviewed-by: enne <enne@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#497679}
The animation logic in the BrowserControlsOffsetManager did not
previously account for bottom controls when triggering an early exit.
This change only skips animation if both top and bottom browser
controls are 0.
BUG=713911
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I9b4a24abfcb3cdd9184370d7bc401dbdec37daa9
Reviewed-on: https://chromium-review.googlesource.com/557953
Reviewed-by: Alexandre Elias <aelias@chromium.org>
Reviewed-by: Ted Choc <tedchoc@chromium.org>
Commit-Queue: Matthew Jones <mdjones@chromium.org>
Cr-Commit-Position: refs/heads/master@{#487497}
This CL adds #include "base/memory/ptr_util.h" to any .h/.cc/.cpp/.mm
file that contains the string "base::MakeUnique" or "base::WrapUnique"
on a line that doesn't start with "//" and whose corresponding .h file
doesn't already contain the include.
.h files are processed first so that the #include is not added to a
.cc/.cpp/.mm file if it is also added to the corresponding .h file.
tools/sort-headers.py was applied to affected files.
TBR=brettw@chromium.org
BUG=675631
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
Review-Url: https://codereview.chromium.org/2598963005
Cr-Commit-Position: refs/heads/master@{#440654}
This change allows the TopControlsManager to correctly compute the
bottom controls offset regardless of the top controls state. This
is done by separately tracking the bottom controls content offset
and using it when the top controls have no height.
BUG=652892
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
Review-Url: https://codereview.chromium.org/2442473002
Cr-Commit-Position: refs/heads/master@{#430476}
They're only used by the ResourceProvider, so there's no fundamental reason for
them to take a separate path through the compositor. Besides, it is natural that
the CompositorFrameSink contains all the objects needed to create resources, all
at the same place. Finally, it's less code overall.
BUG=None
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
Review-Url: https://codereview.chromium.org/2452483002
Cr-Commit-Position: refs/heads/master@{#428551}
This change renames TopControls* to BrowserControls*. This is done
to represent the fact that the toolbar/controls for the browser are
not necessarily at the top of the screen.
BUG=652892
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
Review-Url: https://codereview.chromium.org/2443613002
Cr-Commit-Position: refs/heads/master@{#428054}
