Implement Overscroll Effects on Non-root Scrollers [chromium/src : main]

0 views
Skip to first unread message

Free Debreuil (Gerrit)

unread,
Oct 28, 2025, 10:25:06 AM (8 days ago) Oct 28
to Robert Flack, Peter Beverloo, AyeAye, AI Code Reviewer, Chromium LUCI CQ, chromium...@chromium.org, alexmo...@chromium.org, permissio...@chromium.org, jmedle...@chromium.org, lizeb+watch...@chromium.org, ios-revie...@chromium.org, devtools...@chromium.org, navigation...@chromium.org, creis...@chromium.org, chrome-waff...@google.com, browser-comp...@chromium.org, ios-r...@chromium.org, network-ser...@chromium.org, marq+...@chromium.org, blink-...@chromium.org, cc-...@chromium.org, kinuko...@chromium.org
Attention needed from Robert Flack

Free Debreuil added 1 comment

Patchset-level comments
File-level comment, Patchset 31 (Latest):
Free Debreuil . resolved

PTAL :) I think some changes will be needed, but sending out a first pass for feedback.

Open in Gerrit

Related details

Attention is currently required from:
  • Robert Flack
Submit Requirements:
  • requirement satisfiedCode-Coverage
  • requirement is not satisfiedCode-Owners
  • requirement is not satisfiedCode-Review
  • requirement is not satisfiedNo-Unresolved-Comments
  • requirement is not satisfiedReview-Enforcement
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. DiffyGerrit
Gerrit-MessageType: comment
Gerrit-Project: chromium/src
Gerrit-Branch: main
Gerrit-Change-Id: I54e268e193ec4f023344888c5b2f13a2839dd6de
Gerrit-Change-Number: 7050219
Gerrit-PatchSet: 31
Gerrit-Owner: Free Debreuil <freede...@google.com>
Gerrit-Reviewer: Free Debreuil <freede...@google.com>
Gerrit-Reviewer: Robert Flack <fla...@chromium.org>
Gerrit-CC: AI Code Reviewer <peep-gen...@system.gserviceaccount.com>
Gerrit-CC: Peter Beverloo <pe...@chromium.org>
Gerrit-Attention: Robert Flack <fla...@chromium.org>
Gerrit-Comment-Date: Tue, 28 Oct 2025 14:24:58 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
satisfied_requirement
unsatisfied_requirement
open
diffy

Free Debreuil (Gerrit)

unread,
Oct 29, 2025, 4:39:30 PM (7 days ago) Oct 29
to Robert Flack, Peter Beverloo, AyeAye, AI Code Reviewer, Chromium LUCI CQ, chromium...@chromium.org, alexmo...@chromium.org, permissio...@chromium.org, jmedle...@chromium.org, lizeb+watch...@chromium.org, ios-revie...@chromium.org, devtools...@chromium.org, navigation...@chromium.org, creis...@chromium.org, chrome-waff...@google.com, browser-comp...@chromium.org, ios-r...@chromium.org, network-ser...@chromium.org, marq+...@chromium.org, blink-...@chromium.org, cc-...@chromium.org, kinuko...@chromium.org
Attention needed from Robert Flack

Free Debreuil added 2 comments

File third_party/blink/renderer/platform/widget/input/elastic_overscroll_controller.h
Line 64, Patchset 1: void ObserveScrollUpdate(cc::ElementId element_id,
AI Code Reviewer . resolved

Blink Style Guide: Naming - May leave obvious parameter names out of function declarations. The parameter name `element_id` can be omitted from the function declaration in the header file as its type `cc::ElementId` makes its purpose clear. Please consider applying this to other modified function declarations in this file where applicable.

_To keep this interaction as brief and non-intrusive as possible, please consider responding with one of following options:
**Done** | **Won't fix**: reason | **b/<bug_id>** | **Invalid:** reason

This comment was generated by [Experimental Blink C++ Code Review Agent](http://go/blink-c++-code-review-agent).AI reviews can sometimes be inaccurate; We appreciate your 🙏 feedback 🙏 to help us improve.[File a bug](http://go/blink-c++-code-review-agent-feedback) | [Provide feedback on chat](https://chat.google.com/room/AAQA0zhQHe0?cls=4) | [Opt-out](https://ganpati2.corp.google.com/group/peep-genai-blink-agent-optout.prod)_

Free Debreuil

Done

File third_party/blink/renderer/platform/widget/input/input_handler_proxy.h
Line 269, Patchset 1: // Returns the ElementId of the currently latched scroller, or invalid id.
AI Code Reviewer . resolved

nit: Blink Style Guide: Naming - Precede setters with the word “Set”; use bare words for getters. This getter could be named `LatchedScrollerElementId()`.

_To keep this interaction as brief and non-intrusive as possible, please consider responding with one of following options:
**Done** | **Won't fix**: reason | **b/<bug_id>** | **Invalid:** reason

This comment was generated by [Experimental Blink C++ Code Review Agent](http://go/blink-c++-code-review-agent).AI reviews can sometimes be inaccurate; We appreciate your 🙏 feedback 🙏 to help us improve.[File a bug](http://go/blink-c++-code-review-agent-feedback) | [Provide feedback on chat](https://chat.google.com/room/AAQA0zhQHe0?cls=4) | [Opt-out](https://ganpati2.corp.google.com/group/peep-genai-blink-agent-optout.prod)_

Free Debreuil

Done

Open in Gerrit

Related details

Attention is currently required from:
  • Robert Flack
Submit Requirements:
    • requirement satisfiedCode-Coverage
    • requirement is not satisfiedCode-Owners
    • requirement is not satisfiedCode-Review
    • requirement is not satisfiedReview-Enforcement
    Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. DiffyGerrit
    Gerrit-MessageType: comment
    Gerrit-Project: chromium/src
    Gerrit-Branch: main
    Gerrit-Change-Id: I54e268e193ec4f023344888c5b2f13a2839dd6de
    Gerrit-Change-Number: 7050219
    Gerrit-PatchSet: 34
    Gerrit-Owner: Free Debreuil <freede...@google.com>
    Gerrit-Reviewer: Free Debreuil <freede...@google.com>
    Gerrit-Reviewer: Robert Flack <fla...@chromium.org>
    Gerrit-CC: AI Code Reviewer <peep-gen...@system.gserviceaccount.com>
    Gerrit-CC: Peter Beverloo <pe...@chromium.org>
    Gerrit-Attention: Robert Flack <fla...@chromium.org>
    Gerrit-Comment-Date: Wed, 29 Oct 2025 20:39:25 +0000
    Gerrit-HasComments: Yes
    Gerrit-Has-Labels: No
    Comment-In-Reply-To: AI Code Reviewer <peep-gen...@system.gserviceaccount.com>
    satisfied_requirement
    unsatisfied_requirement
    open
    diffy

    Robert Flack (Gerrit)

    unread,
    Oct 30, 2025, 1:39:41 PM (6 days ago) Oct 30
    to Free Debreuil, Peter Beverloo, AyeAye, AI Code Reviewer, Chromium LUCI CQ, chromium...@chromium.org, alexmo...@chromium.org, permissio...@chromium.org, jmedle...@chromium.org, lizeb+watch...@chromium.org, ios-revie...@chromium.org, devtools...@chromium.org, navigation...@chromium.org, creis...@chromium.org, chrome-waff...@google.com, browser-comp...@chromium.org, ios-r...@chromium.org, network-ser...@chromium.org, marq+...@chromium.org, blink-...@chromium.org, cc-...@chromium.org, kinuko...@chromium.org
    Attention needed from Free Debreuil

    Robert Flack added 8 comments

    File cc/input/scroll_elasticity_helper.cc
    Line 92, Patchset 37: if (!is_root && !scroll_node->is_composited) {
    Robert Flack . unresolved

    Add a comment here explaining why.

    Line 109, Patchset 37: auto& elastic_overscroll = host_impl_->active_tree()
    Robert Flack . unresolved

    Can you include the type here instead of using auto so that the reader doesn't have to check what type elastic_overscroll() returns to know what structure it is or what operations are valid on it?

    It's a bit of a fuzzy area when using auto is good or bad but general guidlines are at https://google.github.io/styleguide/cppguide.html#Type_deduction

    Line 144, Patchset 37: if (!is_root && !scroll_node->is_composited) {
    Robert Flack . unresolved

    If the goal is to never stretch a non-composited scroller, then i think you don't need to handle it on line 92, and could convert that to a CHECK. You also need to make sure to clear out any elastic overscrolls on scrollers which become non-composited during a commit in the ScrollTree::operator=.

    File cc/layers/layer_impl.cc
    Line 957, Patchset 37: layer_tree_impl()->OverscrollElasticityTransformNode()) {
    Robert Flack . unresolved

    I have a few concerns with simply trying to undo the local content scale. Is this a problem with root elastic overscroll today?

    If not, is this something we could do in a followup patch to make sure we get the details right?

    If it is, could we move this fix to an earlier patch to the rest of this change?

    There was a prior attempt to avoid rerastering in https://issues.chromium.org/40228454 . In particular, I think we rely on ignoring subtle changes to transform nodes where screen_space_transform_is_animating is true as we don't trigger updates to the raster scale unless we are significantly off.

    File cc/trees/draw_property_utils.cc
    Line 1505, Patchset 37: DirtyTransformForElasticOverscroll(id, layer_tree_impl, property_trees);
    Robert Flack . unresolved

    Rather than iterating over the maps at draw time, we should set the appropriate bits when the elastic overscroll is changed (e.g. when calling ScrollTree::SetElasticOverscroll). This should result in much less book keeping - e.g. we won't have to keep the previous values around.

    File third_party/blink/renderer/platform/widget/input/elastic_overscroll_controller.cc
    Line 125, Patchset 37: // Find an active entry that is actually overscrolled and finish that one.
    Robert Flack . unresolved

    This is concerning. How do we get into this state and can we do this earlier when we have the correct id?

    Line 180, Patchset 37: ObserveScrollUpdate(element_id, event_delta,
    Robert Flack . unresolved

    In this and many other cases we're doing repeated lookups in the entry map for the element. Could we make these methods take an entry instead of an element id?

    Line 388, Patchset 37: helper_->SetStretchAmount(element_id, new_stretch_amount);
    Robert Flack . unresolved

    I think it would be cleaner to set is_animating = true here rather than doing a second pass through the list after.

    Open in Gerrit

    Related details

    Attention is currently required from:
    • Free Debreuil
    Submit Requirements:
      • requirement satisfiedCode-Coverage
      • requirement is not satisfiedCode-Owners
      • requirement is not satisfiedCode-Review
      • requirement is not satisfiedNo-Unresolved-Comments
      • requirement is not satisfiedReview-Enforcement
      Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. DiffyGerrit
      Gerrit-MessageType: comment
      Gerrit-Project: chromium/src
      Gerrit-Branch: main
      Gerrit-Change-Id: I54e268e193ec4f023344888c5b2f13a2839dd6de
      Gerrit-Change-Number: 7050219
      Gerrit-PatchSet: 37
      Gerrit-Owner: Free Debreuil <freede...@google.com>
      Gerrit-Reviewer: Free Debreuil <freede...@google.com>
      Gerrit-Reviewer: Robert Flack <fla...@chromium.org>
      Gerrit-CC: AI Code Reviewer <peep-gen...@system.gserviceaccount.com>
      Gerrit-CC: Peter Beverloo <pe...@chromium.org>
      Gerrit-Attention: Free Debreuil <freede...@google.com>
      Gerrit-Comment-Date: Thu, 30 Oct 2025 17:39:32 +0000
      Gerrit-HasComments: Yes
      Gerrit-Has-Labels: No
      satisfied_requirement
      unsatisfied_requirement
      open
      diffy

      Free Debreuil (Gerrit)

      unread,
      Oct 30, 2025, 3:41:52 PM (6 days ago) Oct 30
      to Robert Flack, Peter Beverloo, AyeAye, AI Code Reviewer, Chromium LUCI CQ, chromium...@chromium.org, alexmo...@chromium.org, permissio...@chromium.org, jmedle...@chromium.org, lizeb+watch...@chromium.org, ios-revie...@chromium.org, devtools...@chromium.org, navigation...@chromium.org, creis...@chromium.org, chrome-waff...@google.com, browser-comp...@chromium.org, ios-r...@chromium.org, network-ser...@chromium.org, marq+...@chromium.org, blink-...@chromium.org, cc-...@chromium.org, kinuko...@chromium.org
      Attention needed from Robert Flack

      Free Debreuil added 1 comment

      File cc/trees/draw_property_utils.cc
      Line 1505, Patchset 37: DirtyTransformForElasticOverscroll(id, layer_tree_impl, property_trees);
      Robert Flack . unresolved

      Rather than iterating over the maps at draw time, we should set the appropriate bits when the elastic overscroll is changed (e.g. when calling ScrollTree::SetElasticOverscroll). This should result in much less book keeping - e.g. we won't have to keep the previous values around.

      Free Debreuil

      Nice, yes that significantly simplifies it. The most recent patch set has this change. We have to be careful to re-apply the overscroll values to the transform when promoting the pending tree to active. (I have added this)

      Please let me know if there are any other cases I am not considering.

      Open in Gerrit

      Related details

      Attention is currently required from:
      • Robert Flack
      Submit Requirements:
      • requirement satisfiedCode-Coverage
      • requirement is not satisfiedCode-Owners
      • requirement is not satisfiedCode-Review
      • requirement is not satisfiedNo-Unresolved-Comments
      • requirement is not satisfiedReview-Enforcement
      Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. DiffyGerrit
      Gerrit-MessageType: comment
      Gerrit-Project: chromium/src
      Gerrit-Branch: main
      Gerrit-Change-Id: I54e268e193ec4f023344888c5b2f13a2839dd6de
      Gerrit-Change-Number: 7050219
      Gerrit-PatchSet: 38
      Gerrit-Owner: Free Debreuil <freede...@google.com>
      Gerrit-Reviewer: Free Debreuil <freede...@google.com>
      Gerrit-Reviewer: Robert Flack <fla...@chromium.org>
      Gerrit-CC: AI Code Reviewer <peep-gen...@system.gserviceaccount.com>
      Gerrit-CC: Peter Beverloo <pe...@chromium.org>
      Gerrit-Attention: Robert Flack <fla...@chromium.org>
      Gerrit-Comment-Date: Thu, 30 Oct 2025 19:41:46 +0000
      Gerrit-HasComments: Yes
      Gerrit-Has-Labels: No
      Comment-In-Reply-To: Robert Flack <fla...@chromium.org>
      satisfied_requirement
      unsatisfied_requirement
      open
      diffy

      Free Debreuil (Gerrit)

      unread,
      Oct 30, 2025, 4:58:27 PM (6 days ago) Oct 30
      to Robert Flack, Peter Beverloo, AyeAye, AI Code Reviewer, Chromium LUCI CQ, chromium...@chromium.org, alexmo...@chromium.org, permissio...@chromium.org, jmedle...@chromium.org, lizeb+watch...@chromium.org, ios-revie...@chromium.org, devtools...@chromium.org, navigation...@chromium.org, creis...@chromium.org, chrome-waff...@google.com, browser-comp...@chromium.org, ios-r...@chromium.org, network-ser...@chromium.org, marq+...@chromium.org, blink-...@chromium.org, cc-...@chromium.org, kinuko...@chromium.org
      Attention needed from Robert Flack

      Free Debreuil added 1 comment

      File cc/layers/layer_impl.cc
      Line 957, Patchset 37: layer_tree_impl()->OverscrollElasticityTransformNode()) {
      Robert Flack . unresolved

      I have a few concerns with simply trying to undo the local content scale. Is this a problem with root elastic overscroll today?

      If not, is this something we could do in a followup patch to make sure we get the details right?

      If it is, could we move this fix to an earlier patch to the rest of this change?

      There was a prior attempt to avoid rerastering in https://issues.chromium.org/40228454 . In particular, I think we rely on ignoring subtle changes to transform nodes where screen_space_transform_is_animating is true as we don't trigger updates to the raster scale unless we are significantly off.

      Free Debreuil

      Yes - I am looking into this now! On main within the `PictureLayerImpl` the tiles seem to be created once, then the `cc::Tile::raster_transform` limits the maximum scaling. Looking into that area - and will compare with my version to find root cause of difference. Thanks 😊

      Gerrit-Comment-Date: Thu, 30 Oct 2025 20:58:21 +0000
      satisfied_requirement
      unsatisfied_requirement
      open
      diffy

      Free Debreuil (Gerrit)

      unread,
      Nov 4, 2025, 10:21:34 AM (yesterday) Nov 4
      to Robert Flack, Peter Beverloo, AyeAye, AI Code Reviewer, Chromium LUCI CQ, chromium...@chromium.org, alexmo...@chromium.org, permissio...@chromium.org, jmedle...@chromium.org, lizeb+watch...@chromium.org, ios-revie...@chromium.org, devtools...@chromium.org, navigation...@chromium.org, creis...@chromium.org, chrome-waff...@google.com, browser-comp...@chromium.org, ios-r...@chromium.org, network-ser...@chromium.org, marq+...@chromium.org, blink-...@chromium.org, cc-...@chromium.org, kinuko...@chromium.org
      Attention needed from Robert Flack

      Free Debreuil added 8 comments

      Free Debreuil . resolved

      PTAL :)

      File cc/input/scroll_elasticity_helper.cc
      Line 92, Patchset 37: if (!is_root && !scroll_node->is_composited) {
      Robert Flack . resolved

      Add a comment here explaining why.

      Free Debreuil

      added comment.

      Line 109, Patchset 37: auto& elastic_overscroll = host_impl_->active_tree()
      Robert Flack . resolved

      Can you include the type here instead of using auto so that the reader doesn't have to check what type elastic_overscroll() returns to know what structure it is or what operations are valid on it?

      It's a bit of a fuzzy area when using auto is good or bad but general guidlines are at https://google.github.io/styleguide/cppguide.html#Type_deduction

      Free Debreuil

      Updated with explicit type, thanks for the reference!

      Line 144, Patchset 37: if (!is_root && !scroll_node->is_composited) {
      Robert Flack . resolved

      If the goal is to never stretch a non-composited scroller, then i think you don't need to handle it on line 92, and could convert that to a CHECK. You also need to make sure to clear out any elastic overscrolls on scrollers which become non-composited during a commit in the ScrollTree::operator=.

      Free Debreuil

      updated.

      File cc/layers/layer_impl.cc
      Line 957, Patchset 37: layer_tree_impl()->OverscrollElasticityTransformNode()) {
      Robert Flack . resolved

      I have a few concerns with simply trying to undo the local content scale. Is this a problem with root elastic overscroll today?

      If not, is this something we could do in a followup patch to make sure we get the details right?

      If it is, could we move this fix to an earlier patch to the rest of this change?

      There was a prior attempt to avoid rerastering in https://issues.chromium.org/40228454 . In particular, I think we rely on ignoring subtle changes to transform nodes where screen_space_transform_is_animating is true as we don't trigger updates to the raster scale unless we are significantly off.

      Free Debreuil

      Yes - I am looking into this now! On main within the `PictureLayerImpl` the tiles seem to be created once, then the `cc::Tile::raster_transform` limits the maximum scaling. Looking into that area - and will compare with my version to find root cause of difference. Thanks 😊

      Free Debreuil

      Resolved by setting `transform_node->has_potential_animation` to true when the animation of the node with elastic overscroll starts.

      Possibly there is an edge case here. I added a TODO, but could also look into before submitting.
      ```
      // TODO (crbug.com/41102897): Look into potential edge case where clearing
      // this on a transform with an animation could result in this value being
      // cleared to false un-intentionally. This would only be an issue for
      // non-root scrollers.
      ```
      File cc/trees/draw_property_utils.cc
      Line 1505, Patchset 37: DirtyTransformForElasticOverscroll(id, layer_tree_impl, property_trees);
      Robert Flack . resolved

      Rather than iterating over the maps at draw time, we should set the appropriate bits when the elastic overscroll is changed (e.g. when calling ScrollTree::SetElasticOverscroll). This should result in much less book keeping - e.g. we won't have to keep the previous values around.

      Free Debreuil

      Nice, yes that significantly simplifies it. The most recent patch set has this change. We have to be careful to re-apply the overscroll values to the transform when promoting the pending tree to active. (I have added this)

      Please let me know if there are any other cases I am not considering.

      Free Debreuil

      Marked as resolved.

      File third_party/blink/renderer/platform/widget/input/elastic_overscroll_controller.cc
      Line 180, Patchset 37: ObserveScrollUpdate(element_id, event_delta,
      Robert Flack . unresolved

      In this and many other cases we're doing repeated lookups in the entry map for the element. Could we make these methods take an entry instead of an element id?

      Free Debreuil

      Looking through the methods in this class, most use cases require both the `ElementId` and `OverscrollEntry`. To cleanly pass in just the entry, I think we would need to store the `ElementId` on the `OverscrollEntry`.

      It might be straightforward to convert the storage of the `OverscrollEntries` from a `base::flat_map` to a `base::flat_set` and add a custom equality / comparator that allows lookup based on `ElementId` instead of `OverscrollEntry`?

      Line 388, Patchset 37: helper_->SetStretchAmount(element_id, new_stretch_amount);
      Robert Flack . resolved

      I think it would be cleaner to set is_animating = true here rather than doing a second pass through the list after.

      Free Debreuil

      Updated thanks!

      Open in Gerrit

      Related details

      Attention is currently required from:
      • Robert Flack
      Submit Requirements:
      • requirement satisfiedCode-Coverage
      • requirement is not satisfiedCode-Owners
      • requirement is not satisfiedCode-Review
      • requirement is not satisfiedNo-Unresolved-Comments
      • requirement is not satisfiedReview-Enforcement
      Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. DiffyGerrit
      Gerrit-MessageType: comment
      Gerrit-Project: chromium/src
      Gerrit-Branch: main
      Gerrit-Change-Id: I54e268e193ec4f023344888c5b2f13a2839dd6de
      Gerrit-Change-Number: 7050219
      Gerrit-PatchSet: 47
      Gerrit-Owner: Free Debreuil <freede...@google.com>
      Gerrit-Reviewer: Free Debreuil <freede...@google.com>
      Gerrit-Reviewer: Robert Flack <fla...@chromium.org>
      Gerrit-CC: AI Code Reviewer <peep-gen...@system.gserviceaccount.com>
      Gerrit-CC: Peter Beverloo <pe...@chromium.org>
      Gerrit-Attention: Robert Flack <fla...@chromium.org>
      Gerrit-Comment-Date: Tue, 04 Nov 2025 15:21:28 +0000
      Gerrit-HasComments: Yes
      Gerrit-Has-Labels: No
      Comment-In-Reply-To: Free Debreuil <freede...@google.com>
      Comment-In-Reply-To: Robert Flack <fla...@chromium.org>
      satisfied_requirement
      unsatisfied_requirement
      open
      diffy

      Robert Flack (Gerrit)

      unread,
      Nov 4, 2025, 3:17:17 PM (yesterday) Nov 4
      to Free Debreuil, Peter Beverloo, AyeAye, AI Code Reviewer, Chromium LUCI CQ, chromium...@chromium.org, alexmo...@chromium.org, permissio...@chromium.org, jmedle...@chromium.org, lizeb+watch...@chromium.org, ios-revie...@chromium.org, devtools...@chromium.org, navigation...@chromium.org, creis...@chromium.org, chrome-waff...@google.com, browser-comp...@chromium.org, ios-r...@chromium.org, network-ser...@chromium.org, marq+...@chromium.org, blink-...@chromium.org, cc-...@chromium.org, kinuko...@chromium.org
      Attention needed from Free Debreuil

      Robert Flack added 2 comments

      File third_party/blink/renderer/platform/widget/input/elastic_overscroll_controller.cc
      Line 125, Patchset 37: // Find an active entry that is actually overscrolled and finish that one.
      Robert Flack . unresolved

      This is concerning. How do we get into this state and can we do this earlier when we have the correct id?

      Robert Flack

      Any thoughts on this fallback code? Do you have a repro case? Can we detect when the element id goes away and do the cleanup then?

      Line 180, Patchset 37: ObserveScrollUpdate(element_id, event_delta,
      Robert Flack . unresolved

      In this and many other cases we're doing repeated lookups in the entry map for the element. Could we make these methods take an entry instead of an element id?

      Free Debreuil

      Looking through the methods in this class, most use cases require both the `ElementId` and `OverscrollEntry`. To cleanly pass in just the entry, I think we would need to store the `ElementId` on the `OverscrollEntry`.

      It might be straightforward to convert the storage of the `OverscrollEntries` from a `base::flat_map` to a `base::flat_set` and add a custom equality / comparator that allows lookup based on `ElementId` instead of `OverscrollEntry`?

      Robert Flack

      In the short term I wouldn't worry about having the ElementId as both the key and in the stored member. It's true this could just be a flat_set but we could always do this as a followup or alternately you could pass both the element id and the entry through.

      Open in Gerrit

      Related details

      Attention is currently required from:
      • Free Debreuil
      Submit Requirements:
      • requirement satisfiedCode-Coverage
      • requirement is not satisfiedCode-Owners
      • requirement is not satisfiedCode-Review
      • requirement is not satisfiedNo-Unresolved-Comments
      • requirement is not satisfiedReview-Enforcement
      Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. DiffyGerrit
      Gerrit-MessageType: comment
      Gerrit-Project: chromium/src
      Gerrit-Branch: main
      Gerrit-Change-Id: I54e268e193ec4f023344888c5b2f13a2839dd6de
      Gerrit-Change-Number: 7050219
      Gerrit-PatchSet: 47
      Gerrit-Owner: Free Debreuil <freede...@google.com>
      Gerrit-Reviewer: Free Debreuil <freede...@google.com>
      Gerrit-Reviewer: Robert Flack <fla...@chromium.org>
      Gerrit-CC: AI Code Reviewer <peep-gen...@system.gserviceaccount.com>
      Gerrit-CC: Peter Beverloo <pe...@chromium.org>
      Gerrit-Attention: Free Debreuil <freede...@google.com>
      Gerrit-Comment-Date: Tue, 04 Nov 2025 20:17:13 +0000
      satisfied_requirement
      unsatisfied_requirement
      open
      diffy

      Free Debreuil (Gerrit)

      unread,
      Nov 4, 2025, 3:25:25 PM (yesterday) Nov 4
      to Robert Flack, Peter Beverloo, AyeAye, AI Code Reviewer, Chromium LUCI CQ, chromium...@chromium.org, alexmo...@chromium.org, permissio...@chromium.org, jmedle...@chromium.org, lizeb+watch...@chromium.org, ios-revie...@chromium.org, devtools...@chromium.org, navigation...@chromium.org, creis...@chromium.org, chrome-waff...@google.com, browser-comp...@chromium.org, ios-r...@chromium.org, network-ser...@chromium.org, marq+...@chromium.org, blink-...@chromium.org, cc-...@chromium.org, kinuko...@chromium.org
      Attention needed from Robert Flack

      Free Debreuil added 1 comment

      File third_party/blink/renderer/platform/widget/input/elastic_overscroll_controller.cc
      Line 125, Patchset 37: // Find an active entry that is actually overscrolled and finish that one.
      Robert Flack . unresolved

      This is concerning. How do we get into this state and can we do this earlier when we have the correct id?

      Robert Flack

      Any thoughts on this fallback code? Do you have a repro case? Can we detect when the element id goes away and do the cleanup then?

      Free Debreuil

      I am looking into this one currently - I can repro in Chrome by scrolling multiple times in different scrollers w/ overscroll - possibly it would be good to make a test that simulates this as well.

      From what I can tell so far, in `InputHandlerProxy` during the gesture lifecycle (`HandleGestureScrollBegin`, `Update`, etc..) the `CurrentlyScrollingNode` (from the `ScrollTree`) seems to be being cleared - which results in the issue. I'm looking into exactly what is clearing it now : )

      We could possibly detect during the `HandleGestureScrollUpdate` if the `CurrentlyScrollingNode` is cleared - and do something then if needed.

      Open in Gerrit

      Related details

      Attention is currently required from:
      • Robert Flack
      Submit Requirements:
      • requirement satisfiedCode-Coverage
      • requirement is not satisfiedCode-Owners
      • requirement is not satisfiedCode-Review
      • requirement is not satisfiedNo-Unresolved-Comments
      • requirement is not satisfiedReview-Enforcement
      Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. DiffyGerrit
      Gerrit-MessageType: comment
      Gerrit-Project: chromium/src
      Gerrit-Branch: main
      Gerrit-Change-Id: I54e268e193ec4f023344888c5b2f13a2839dd6de
      Gerrit-Change-Number: 7050219
      Gerrit-PatchSet: 47
      Gerrit-Owner: Free Debreuil <freede...@google.com>
      Gerrit-Reviewer: Free Debreuil <freede...@google.com>
      Gerrit-Reviewer: Robert Flack <fla...@chromium.org>
      Gerrit-CC: AI Code Reviewer <peep-gen...@system.gserviceaccount.com>
      Gerrit-CC: Peter Beverloo <pe...@chromium.org>
      Gerrit-Attention: Robert Flack <fla...@chromium.org>
      Gerrit-Comment-Date: Tue, 04 Nov 2025 20:25:20 +0000
      Gerrit-HasComments: Yes
      Gerrit-Has-Labels: No
      Comment-In-Reply-To: Robert Flack <fla...@chromium.org>
      satisfied_requirement
      unsatisfied_requirement
      open
      diffy

      Robert Flack (Gerrit)

      unread,
      4:04 PM (1 hour ago) 4:04 PM
      to Free Debreuil, Peter Beverloo, AyeAye, AI Code Reviewer, Chromium LUCI CQ, chromium...@chromium.org, alexmo...@chromium.org, permissio...@chromium.org, jmedle...@chromium.org, lizeb+watch...@chromium.org, ios-revie...@chromium.org, devtools...@chromium.org, navigation...@chromium.org, creis...@chromium.org, chrome-waff...@google.com, browser-comp...@chromium.org, ios-r...@chromium.org, network-ser...@chromium.org, marq+...@chromium.org, blink-...@chromium.org, cc-...@chromium.org, kinuko...@chromium.org
      Attention needed from Free Debreuil

      Robert Flack added 1 comment

      File third_party/blink/renderer/platform/widget/input/elastic_overscroll_controller.cc
      Line 125, Patchset 37: // Find an active entry that is actually overscrolled and finish that one.
      Robert Flack . unresolved

      This is concerning. How do we get into this state and can we do this earlier when we have the correct id?

      Robert Flack

      Any thoughts on this fallback code? Do you have a repro case? Can we detect when the element id goes away and do the cleanup then?

      Free Debreuil

      I am looking into this one currently - I can repro in Chrome by scrolling multiple times in different scrollers w/ overscroll - possibly it would be good to make a test that simulates this as well.

      From what I can tell so far, in `InputHandlerProxy` during the gesture lifecycle (`HandleGestureScrollBegin`, `Update`, etc..) the `CurrentlyScrollingNode` (from the `ScrollTree`) seems to be being cleared - which results in the issue. I'm looking into exactly what is clearing it now : )

      We could possibly detect during the `HandleGestureScrollUpdate` if the `CurrentlyScrollingNode` is cleared - and do something then if needed.

      Robert Flack

      Yeah that would be what I would expect, that if we clear the currently scrolling node then we effectively "end" the user scrolling on that node.

      Open in Gerrit

      Related details

      Attention is currently required from:
      • Free Debreuil
      Submit Requirements:
      • requirement satisfiedCode-Coverage
      • requirement is not satisfiedCode-Owners
      • requirement is not satisfiedCode-Review
      • requirement is not satisfiedNo-Unresolved-Comments
      • requirement is not satisfiedReview-Enforcement
      Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. DiffyGerrit
      Gerrit-MessageType: comment
      Gerrit-Project: chromium/src
      Gerrit-Branch: main
      Gerrit-Change-Id: I54e268e193ec4f023344888c5b2f13a2839dd6de
      Gerrit-Change-Number: 7050219
      Gerrit-PatchSet: 47
      Gerrit-Owner: Free Debreuil <freede...@google.com>
      Gerrit-Reviewer: Free Debreuil <freede...@google.com>
      Gerrit-Reviewer: Robert Flack <fla...@chromium.org>
      Gerrit-CC: AI Code Reviewer <peep-gen...@system.gserviceaccount.com>
      Gerrit-CC: Peter Beverloo <pe...@chromium.org>
      Gerrit-Attention: Free Debreuil <freede...@google.com>
      Gerrit-Comment-Date: Wed, 05 Nov 2025 21:04:25 +0000
      Gerrit-HasComments: Yes
      Gerrit-Has-Labels: No
      satisfied_requirement
      unsatisfied_requirement
      open
      diffy
      Reply all
      Reply to author
      Forward
      0 new messages