This metric is recorded in an enum histogram once per gesture.
The enum values correspond to reason/state of the current navigation and
any other existing navigation in the background.
Bug: 349815498
Change-Id: I7f06609dd574492b997a1f572a844c3f6b7f91d1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5833108
Reviewed-by: Alexei Svitkine <asvitkine@chromium.org>
Reviewed-by: Vladimir Levin <vmpstr@chromium.org>
Commit-Queue: Baran Erfani <baranerf@google.com>
Cr-Commit-Position: refs/heads/main@{#1352095}
This metric counts the number of times that an input with type
WebInputEvent::Type::kTouchStart is ignored while the animator is
processing/animating (in animation invoked and canceled cases).
Note: This CL only has the plumbing part to get the input event.
The subsequent CL will include the implementation of `MaybeRecordIgnoredInput`.
Bug: 331778097
Change-Id: Ieffeae77422c0add24a4f3a1a8738d26acd3db7a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5783845
Commit-Queue: Baran Erfani <baranerf@google.com>
Reviewed-by: William Liu <liuwilliam@chromium.org>
Reviewed-by: Khushal Sagar <khushalsagar@chromium.org>
Reviewed-by: Vladimir Levin <vmpstr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1347017}
We currently miss plumbing this bit to the renderer since it's set on
the navigation request after the commit message is already sent. Fix
that timing and update the browser test to include the complete flow.
Bug: 331671779
Change-Id: I857dbe903e746945e5e5c06146bc0c83c8ade0f5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5804907
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Auto-Submit: Khushal Sagar <khushalsagar@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: William Liu <liuwilliam@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1345671}
We might have a screenshot stay on top of the live page, after the
navigation commits, if the new renderer does not produce a frame (e.g.,
a very busy renderer main thread).
While this should be very rare, we still need a grace failsafe. In this
CL we simply remove the screenshot and terminate the animator (skipping
the crossfade) if the new renderer fails to produce a new frame after
four seconds
Fixed: 360844863
Change-Id: I404e8adefc3899d5cc21f8a514815744b6f0a68e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5797899
Commit-Queue: William Liu <liuwilliam@chromium.org>
Reviewed-by: Khushal Sagar <khushalsagar@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1345579}
In order to implement a timer for navigation transition, we should
disable the paint holding timer. We don't want to let the navigation
transition timer fire so we crossfade from the screenshot of the
current page to the fallback surface of the previous page, and then let
the paint holding timer fire to dismiss the fallback surface, if the
new renderer doesn't produce a frame in time.
In other words we "upgrade" from the paint holding timer to the
navigation transition timer, if a history navigation is being animated.
Another alternative is to purposefully give the navigation transition
timer a longer duration, so it always fires after paint holding. Didn't
implement that approach because I didn't want this feature to be
dependent on paint holding.
Bug: 360844863
Change-Id: Ieaa95359dd3cd3418e7d739f9b747a22b2bc5082
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5797563
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Khushal Sagar <khushalsagar@chromium.org>
Commit-Queue: William Liu <liuwilliam@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1344896}
NOTREACHED() has turned [[noreturn]] so the former macro isn't needed
anymore.
This does not attempt to do a rewrite of any surrounding code, like:
if (!foo) {
NOTREACHED();
}
to CHECK(foo);
Those transforms take a non-trivial amount of time (and there are
thousands of instances). Cleanup can be left as an exercise for the
reader.
NO_IFTTT=No-op-rename migration.
Bug: 40580068
Change-Id: I068c5fdce9dc4c352d8bdd62bb3cd2c0a2d59659
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5782602
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Owners-Override: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Peter Boström <pbos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1342096}
This relands commit 2931e7e8b0 which
was reverted in commit 4822abbbc7
Original CL in first uploaded patchset, diff from PS1 for changes.
The test would fail if the RFH is reused so the last render frame
metadata has a valid sequence number but not the one that's being
waited on.
Bug: 331778101
Change-Id: Ib57b8f07aa0063c334169cb3da4dd54ec995378b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5784917
Reviewed-by: William Liu <liuwilliam@chromium.org>
Commit-Queue: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1341704}
These tests currently perform most assertions/expectations within the
test harness rather than in the test body. Failing assertions outside
the test body don't cause the test to stop and require looking at the
stacktrace to understand where in a test the failure is coming from.
Android stacks are often incomplete on bots which makes tests difficult
to debug.
This mega CL (sorry) removes almost all of the harness asserting logic
and places the checks in test bodies. New tests are added to
preserve coverage where needed. High level changes:
* Replaced all the transform checks (ExpectedLayerTransforms) with
explicit checks in tests.
* Exposed layers to tests explicitly, rather than relying on indexes.
* Exposed animator state to tests and check it inline in test body.
* Replaced most uses of callback with TestFuture and other minor
cleanups.
The aim is for tests to be Descriptive And Meaningful Phrases
(DAMP[1]), even at the cost of some repetition. Having checks inside
the harness is:
* Difficult to tell what each individual test is actually checking for.
* Each test effectively tests _everything_ so a single defect can cause
many test failures and extremely verbose logs.
* Adding new functionality (e.g. RTL, Forward nav) means logic inside
the harness gets more complex and stateful. Risk losing coverage if
there's logic bugs.
* To understand what a test is doing requires learning the entire
harness.
[1] https://abseil.io/resources/swe-book/html/ch12.html#:~:text=and%20Code%20Sharing%3A-,DAMP%2C%20Not%20DRY,-One%20final%C2%A0
Change-Id: I9fb78b3c80adf537a3f168b6ae54e426c956315a
Bug: 331778101
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5780030
Commit-Queue: David Bokan <bokan@chromium.org>
Reviewed-by: William Liu <liuwilliam@chromium.org>
Reviewed-by: Khushal Sagar <khushalsagar@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1341464}
This change enables input suppression during a back forward transition
with the following changes from the previous attempt:
1. Input suppression starts when the swipe gesture ends, i.e., we have a
touch up which either starts a navigation or cancels the gesture. This
ensures the suppression doesn't start mid-gesture, which is the case
in 3-button navigation mode where the navigation gesture is driven by
overscroll events from the renderer.
2. Fix the order of resetting gesture detection in RWHVAndroid. Resetting the gesture detector involves generating synthetic touch
cancel events if the user started a drag during the input suppression
period. This can create the following situation:
a) We get touch start/move events during input suppression.
GestureDetector maps these to scroll start/update events which are
not propagated further due to input suppression.
b) When ending input suppression, resetting the gesture detector sends
a synthetic cancel event which maps to a gesture scroll end event.
Since suppression is now over, the scroll end event is propagated
while it's corresponding scroll start event was suppressed.
Avoid the above by resetting the gesture detector right before
unsuppressing input.
Fixed: 344620149
Change-Id: I09103843e026fb32af670b99ecee6552bd1ff055
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5777543
Auto-Submit: Khushal Sagar <khushalsagar@chromium.org>
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1341073}
Change the scrim behavior. Before, the scrim animation is 0.8->0.3
during the invoke animation then 0.3->0 during the crossfade; in this CL
the scrim is only applied during the invoke animation, and is from
0.2->0 for light mode and 0.1->0 in light mode.
The Surface0 color will be used for the final fallback UX impl, which
isn't finch blocking.
Bug: 40260440
Change-Id: I6f840193b6e01daa63e7ede962fd537cbb530324
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5769672
Reviewed-by: Khushal Sagar <khushalsagar@chromium.org>
Commit-Queue: William Liu <liuwilliam@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1339666}
This is a reland of commit 1ea3357521
Revert reason: in some subframe tests, in order to create one main
frame request and one subframe request in one GoToIndex(), we are
navigating the mainframe same-doc while navigating the subframe
cross-doc. For the mainframe same-doc navigation, the LSID increment
experiment flag is required to capture the screenshot.
The fix is diff PS1..onward, where we enable the LSID flag for all
tests.
Tested with the exact android-arm-test build.
Original change's description:
> [DNT] Track subframe navigation requests
>
> For any navigation:
> - If there is a main frame navigation request, we track the main frame
> request regardless of any subframe navigation requests.
> - If there is no main frame request, we only track the navigation with
> exactly one subframe request. The navigation with >1 subframe requests
> won't be animated.
>
> Since no subframe navigation screenshots are captured, we will show the
> fallback UX during the subframe transitions.
>
> Note: when a primary main frame request commits, we cancel the ongoing
> subframe transition. The stack is:
> - DidFinishNav() called for the subframe request. Since the nav_handle
> has not committed, we play the cancel animation.
> - If by the time the main frame request commits, the cancel animation
> is still playing, OnDidNavigatePrimaryMainFramePreCommit() will be
> called for the main frame request. We then transit from
> kDisplayingCancelAnimation to kAnimationAborted.
>
> Bug: 41490714, 357060513
> Change-Id: Idb6135b3ba272d4b3f15a1b9f48a9cbf699ddb70
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5738894
> Reviewed-by: David Bokan <bokan@chromium.org>
> Commit-Queue: William Liu <liuwilliam@chromium.org>
> Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
> Reviewed-by: Khushal Sagar <khushalsagar@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1337863}
Bug: 41490714, 357060513
Change-Id: I0a05dbbd690efeb4c433c95ecea9ea272a57cc73
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5769855
Commit-Queue: William Liu <liuwilliam@chromium.org>
Reviewed-by: Khushal Sagar <khushalsagar@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1339051}
This reverts commit 1ea3357521.
Reason for revert:
OneMainFrameRequest_OneSubframeRequest is failing
Original change's description:
> [DNT] Track subframe navigation requests
>
> For any navigation:
> - If there is a main frame navigation request, we track the main frame
> request regardless of any subframe navigation requests.
> - If there is no main frame request, we only track the navigation with
> exactly one subframe request. The navigation with >1 subframe requests
> won't be animated.
>
> Since no subframe navigation screenshots are captured, we will show the
> fallback UX during the subframe transitions.
>
> Note: when a primary main frame request commits, we cancel the ongoing
> subframe transition. The stack is:
> - DidFinishNav() called for the subframe request. Since the nav_handle
> has not committed, we play the cancel animation.
> - If by the time the main frame request commits, the cancel animation
> is still playing, OnDidNavigatePrimaryMainFramePreCommit() will be
> called for the main frame request. We then transit from
> kDisplayingCancelAnimation to kAnimationAborted.
>
> Bug: 41490714, 357060513
> Change-Id: Idb6135b3ba272d4b3f15a1b9f48a9cbf699ddb70
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5738894
> Reviewed-by: David Bokan <bokan@chromium.org>
> Commit-Queue: William Liu <liuwilliam@chromium.org>
> Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
> Reviewed-by: Khushal Sagar <khushalsagar@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1337863}
Bug: 41490714, 357060513, 358033372
Change-Id: If8dd8d2db1bb9ff13db2937c6dd0b596901f44fb
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5767295
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Michael van Ouwerkerk <mvanouwerkerk@chromium.org>
Reviewed-by: Michael van Ouwerkerk <mvanouwerkerk@chromium.org>
Owners-Override: Michael van Ouwerkerk <mvanouwerkerk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1338414}
For any navigation:
- If there is a main frame navigation request, we track the main frame
request regardless of any subframe navigation requests.
- If there is no main frame request, we only track the navigation with
exactly one subframe request. The navigation with >1 subframe requests
won't be animated.
Since no subframe navigation screenshots are captured, we will show the
fallback UX during the subframe transitions.
Note: when a primary main frame request commits, we cancel the ongoing
subframe transition. The stack is:
- DidFinishNav() called for the subframe request. Since the nav_handle
has not committed, we play the cancel animation.
- If by the time the main frame request commits, the cancel animation
is still playing, OnDidNavigatePrimaryMainFramePreCommit() will be
called for the main frame request. We then transit from
kDisplayingCancelAnimation to kAnimationAborted.
Bug: 41490714, 357060513
Change-Id: Idb6135b3ba272d4b3f15a1b9f48a9cbf699ddb70
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5738894
Reviewed-by: David Bokan <bokan@chromium.org>
Commit-Queue: William Liu <liuwilliam@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Khushal Sagar <khushalsagar@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1337863}
This patch fixes the way we get rid of the animator in cases of chained
back. The destructor of the animator CHECKs that we're in a terminal
state, so just resetting the animator can trigger that. Instead, abort
the animation and destroy via the destruction calls. This also cleans
up the observers appropriately.
R=khushalsagar@chromium.org, liuwilliam@chromium.org
Change-Id: Ia18c08de6ad6078933f6721919d6696b67fd9855
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5758278
Commit-Queue: Vladimir Levin <vmpstr@chromium.org>
Reviewed-by: Khushal Sagar <khushalsagar@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1336203}
crrev.com/5744060 added screenshot compression but the size of the
encoded bitmap was computed incorrectly. This resulted in an error when
uploading the compressed bitmap to GPU memory during the transition.
Fix this and also pull out the compression code to a common helper
method so it can be shared with compression for tab switcher
screenshots.
TBR=rbyers@chromium.org
Bug: 40256003
Change-Id: I639eedfdd11111b403d81c3787da3720cbaefaed
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5750244
Auto-Submit: Khushal Sagar <khushalsagar@chromium.org>
Reviewed-by: Theresa Sullivan <twellington@chromium.org>
Commit-Queue: Khushal Sagar <khushalsagar@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1335782}
Say we capture a screenshot of page A with the top control shown. If the
top control is hidden on page B, when we transit back to A we will be
showing the canvas at the bottom for the screenshot preview.
One way to go around this is to always force the browser top control to
be fully visible at the start of the transition.
The change in cc/input/browser_controls_offset_manager.cc is required
for three-button mode because the gesture in three button mode is
considered as a scroll. When the gesture is dispatched from the OS:
- BrowserControlsOffsetManager::ScrollBegin
- BrowserControlsOffsetManager::ScrollBy
- Clank gets the gesture, and starts to animate down the TC.
- BrowserControlsOffsetManager::UpdateBrowserControlsState
- Set show_controls_when_scroll_completes_ to true.
- BrowserControlsOffsetManager::ScrollEnd
- Because show_controls_when_scroll_completes_ is true, we try to
reanimate the TC to show, failing a DCHECK[0].
show_controls_when_scroll_completes_ was added in
https://crrev.com/c/4136461 and was used to defer the scroll-initiated
TC animation after browser-driven TC animation.
[0]: https://crsrc.org/c/cc/input/browser_controls_offset_manager.cc;drc=34ad7f3844f882baf3d31a6bc6e300acaa0e3fc8;l=617
Bug: 340292683
Low-Coverage-Reason: TESTS_IN_SEPARATE_CL
Change-Id: I8d42edafb288057d656ad33d91139f5555506c71
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5678714
Reviewed-by: Theresa Sullivan <twellington@chromium.org>
Code-Coverage: findit-for-me@appspot.gserviceaccount.com <findit-for-me@appspot.gserviceaccount.com>
Reviewed-by: Khushal Sagar <khushalsagar@chromium.org>
Commit-Queue: William Liu <liuwilliam@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1332347}
This CL plumbs the edge parameter into BackForwardTransitionAnimator so
that it can be used to mirror the back gesture animation. The caller
(manager) is responsible for determining the direction so the animator
is agnostic of RTL - only that it needs to perform an animation from a
given edge.
Also fix the progress computation in 3-button mode to run from 0 to 1
irrespective of the direction, allowing the animator to fully implement
the animation as well as matching the semantics of BackEventCompat (used
by gestural mode).
Bug: 331778964
Change-Id: Iab5ab3a0422ac8c6450f93804f39299df20a64b5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5690915
Code-Coverage: findit-for-me@appspot.gserviceaccount.com <findit-for-me@appspot.gserviceaccount.com>
Commit-Queue: David Bokan <bokan@chromium.org>
Reviewed-by: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Lijin Shen <lazzzis@google.com>
Reviewed-by: Khushal Sagar <khushalsagar@chromium.org>
Reviewed-by: Theresa Sullivan <twellington@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1331282}
This is a reland of commit f56c7d2306
The cause: when kIncrementLocalSurfaceIdForMainframeSameDocNavigation
is init'ed in SetUp(), the value is _somehow_ not overridden in //blink
when `is_chrome_branded = true` is set in the args.gn.
The fix: ScopedFeatureList should be init'ed in the test harness's ctor.
See diff of PS1..2.
Tested: with `is_chrome_branded = true` in my local dev build dir, and
the android-official bot.
Original change's description:
> [DNT] Clone old surface for same-doc navs
>
> Since we are subscribing to the widget host immediately after the nav
> starts, we might as well clone the old surface at the same spot. This
> way we don't have to add a ReadyToCommitSameDocNav on the
> NavigatorDelegate or RFHDelegate.
>
> Bug: 352526258
> Change-Id: Ic1ea3aa561c47ab0efcc314903369ae6d35f5be3
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5695986
> Commit-Queue: William Liu <liuwilliam@chromium.org>
> Reviewed-by: Khushal Sagar <khushalsagar@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1326326}
Bug: 352526258
Change-Id: I5e1827cb91d3d4ee72ff03e315ca29956cfa3e8a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5708049
Commit-Queue: William Liu <liuwilliam@chromium.org>
Reviewed-by: Khushal Sagar <khushalsagar@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1328313}
When this flag is enabled and if Chrome's UI is in an RTL layout (i.e.
using a right-to-left language like Arabic), navigation gestures will
flip the meaning of the edges, i.e. treat the right edge as "back" and
the left edge as "forward". (Note: only 3-button mode currently
navigates forward from the forward edge. Gestural navigation navigates
back from both edges but doesn't show a transition animation from the
"forward" edge).
Note: this CL implements the flag and passes the right value to the
handler but animations and UI are still broken for the right edge.
Followup CLs will fix these issues.
Bug: 331778964
Change-Id: I7ca92da85a58f66f8cfea0adccafdca5dfe7bdd4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5692438
Reviewed-by: Jinsuk Kim <jinsukkim@chromium.org>
Reviewed-by: Lijin Shen <lazzzis@google.com>
Reviewed-by: William Liu <liuwilliam@chromium.org>
Commit-Queue: David Bokan <bokan@chromium.org>
Reviewed-by: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Theresa Sullivan <twellington@chromium.org>
Code-Coverage: findit-for-me@appspot.gserviceaccount.com <findit-for-me@appspot.gserviceaccount.com>
Reviewed-by: Khushal Sagar <khushalsagar@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1328281}
This reverts commit f56c7d2306.
Reason for revert: Suspected failing on bots, see b/352766243.
Original change's description:
> [DNT] Clone old surface for same-doc navs
>
> Since we are subscribing to the widget host immediately after the nav
> starts, we might as well clone the old surface at the same spot. This
> way we don't have to add a ReadyToCommitSameDocNav on the
> NavigatorDelegate or RFHDelegate.
>
> Bug: 352526258
> Change-Id: Ic1ea3aa561c47ab0efcc314903369ae6d35f5be3
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5695986
> Commit-Queue: William Liu <liuwilliam@chromium.org>
> Reviewed-by: Khushal Sagar <khushalsagar@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1326326}
Bug: 352526258
Change-Id: I7a4b7e08e9eee241b84ba700d227d784d6574b43
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5703542
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Hailey Wang <haileywang@google.com>
Commit-Queue: Hailey Wang <haileywang@google.com>
Auto-Submit: Hailey Wang <haileywang@google.com>
Cr-Commit-Position: refs/heads/main@{#1326886}
https://crrev.com/c/5637535 missed three spots: For
OnDetachedFromWindow, OnRootWindowVisibilityChanged and
OnDetachCompositor we must also advance the animator to
kAnimationAborted, then destroy the animator.
Also reordered some of the definitions in
back_forward_transition_animation_manager_android.cc, such that the
definitions and declarations are in the same order.
Bug: 345518193
Change-Id: I509358eb55de3f079ed4f81d00aaebd314e84965
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5698065
Reviewed-by: Khushal Sagar <khushalsagar@chromium.org>
Commit-Queue: William Liu <liuwilliam@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1326446}
Since we are subscribing to the widget host immediately after the nav
starts, we might as well clone the old surface at the same spot. This
way we don't have to add a ReadyToCommitSameDocNav on the
NavigatorDelegate or RFHDelegate.
Bug: 352526258
Change-Id: Ic1ea3aa561c47ab0efcc314903369ae6d35f5be3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5695986
Commit-Queue: William Liu <liuwilliam@chromium.org>
Reviewed-by: Khushal Sagar <khushalsagar@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1326326}
It hurts my eyes that the declarations and definitions are out of order.
Also since the animator's APIs are mirroring the manager, the mirrored
ones should be in the same order of the manager.
Change-Id: I52faab5c37a08cc4ea1f29e809f8ce9c522ae229
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5695546
Reviewed-by: Khushal Sagar <khushalsagar@chromium.org>
Commit-Queue: Khushal Sagar <khushalsagar@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1326168}
This change fixes the following issues for same-RFH navigations and back
forward visual transitions:
1. The navigation screenshot cache assumes we never persist a screenshot
for the currently committed navigation entry. This assumption is broken
for same-RFH navigations where the screenshot request is sent at the
same time as the commit IPC is sent to the renderer. If the GPU responds
with the screenshot before the renderer responds with DidCommit, the
screenshot is persisted before the navigation has been committed.
Fix this by restructuring the code such that we defer caching the
screenshot until the NavigationRequest is being destroyed.
2. The SurfaceLayer for the outgoing page is cloned during DidCommit
only for cross-RFH navs. This is currently not done for same-RFH navs
and it would be too late in the navigation lifecycle for these navs. This
is because the SurfaceID of the RFH is updated when sending the commit
message for these navs.
Fix the above by cloning the SurfaceLayer in ReadyToCommit.
Note: The current code misses this for same-document navs which should
be fixed separately.
The browser test still forces RenderDocument on all frames, this is
removed in the follow up patch.
R=liuwilliam@chromium.org, rakina@chromium.org
Cq-Include-Trybots: luci.chromium.try:android-10-arm64-rel,android-11-x86-rel,android-12-x64-dbg,android-12l-x64-dbg,android-12-x64-rel,android-13-x64-rel,android-14-x64-rel,android-15-x64-fyi-rel,android-15-x64-rel,android-arm-compile-dbg,android-arm64-all-targets-dbg,android-arm64-rel,android-bfcache-rel,android-cronet-arm64-rel,android-fieldtrial-rel,android-oreo-x86-rel,android-official,android-mte-arm64-rel,android-oreo-arm64-dbg,android-pie-arm64-dbg,android-pie-x86-rel,android-perfetto-rel,android-x64-rel,android-x86-rel,android_blink_rel
Bug: 41491612
Change-Id: I3d12457ba49e6fd6cbc073ebc360986e13bd3d50
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5680502
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Auto-Submit: Khushal Sagar <khushalsagar@chromium.org>
Reviewed-by: William Liu <liuwilliam@chromium.org>
Commit-Queue: William Liu <liuwilliam@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1324372}
The navigation screenshot cache assumes we never persist a screenshot
for the currently committed navigation entry. This assumption is broken
for same-RFH navigations where the screenshot request is sent at the
same time as the commit IPC is sent to the renderer. If the GPU responds
with the screenshot before the renderer responds with DidCommit, the
screenshot is persisted before the navigation has been committed.
Fix this by restructuring the code such that we defer caching the
screenshot until the NavigationRequest is being destroyed.
Cq-Include-Trybots: luci.chromium.try:android-oreo-x86-rel
R=liuwilliam@chromium.org, rakina@chromium.org
Fixed: 41491612
Change-Id: I003e7defdc4ffe9033e335081f5ea41db572a524
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5665181
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: William Liu <liuwilliam@chromium.org>
Commit-Queue: Khushal Sagar <khushalsagar@chromium.org>
Auto-Submit: Khushal Sagar <khushalsagar@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1323131}
- Moved observer definitions to the animation manager
- Added a new State to the animator: kAnimationAborted
- Added a function to the manager to check for the animator state and if it is in a terminal state asynchronously destroy it to avoid calling
SynchronouslyDestroyAnimator from the animator.
Bug: 345518193
Change-Id: I37a95d1a4f28e19221de6321b235897eadc37290
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5637535
Reviewed-by: Khushal Sagar <khushalsagar@chromium.org>
Reviewed-by: William Liu <liuwilliam@chromium.org>
Reviewed-by: Vladimir Levin <vmpstr@chromium.org>
Commit-Queue: William Liu <liuwilliam@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1321123}
If the destination entry doesn't have a screenshot, we on-the-fly
compose a screenshot using the destination page's background color. The
background color was computed by the CSS and stored on the
NavigationEntry.
Bug: 40260440
Change-Id: I338dc0b6b61a475282876ff6705cde62d903fbac
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5622891
Commit-Queue: William Liu <liuwilliam@chromium.org>
Reviewed-by: Khushal Sagar <khushalsagar@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1318744}
