fix : cursor scrolling behaviour

[aaryan182]

fixes : #6773

Issue Description

When scrolling through tables with many records (100+), using the scrollbar would inadvertently select table rows. This happened because while the scrollbar track had the data-select-disable="true" attribute, the scrollbar handle (the part users actually drag) did not have this attribute, allowing it to trigger the drag selection functionality.

Changes Made

Added the data-select-disable="true" attribute to the scrollbar handles (both vertical and horizontal) in the ScrollWrapper component.
Updated both the updated event handler (initial setup) and the scroll event handler to ensure this attribute is consistently applied.
No changes to existing functionality or behavior outside of fixing the scrollbar interaction.

Technical Details

The issue occurred in the ScrollWrapper component where the data-select-disable="true" attribute was correctly being applied to the scrollbar tracks .

tw1.mp4

[github-actions]

Welcome!

Hello there, congrats on your first PR! We're excited to have you contributing to this project.
By submitting your Pull Request, you acknowledge that you agree with the terms of our Contributor License Agreement.

Generated by 🚫 dangerJS against e9f9db3

[greptile-apps]

PR Summary

This PR fixes an issue where using the scrollbar in tables would inadvertently trigger row selection by adding data-select-disable attributes to scrollbar handles.

• Added data-select-disable="true" to scrollbar handles in /packages/twenty-front/src/modules/ui/utilities/scroll/components/ScrollWrapper.tsx
• Implemented attribute setting in both updated and scroll event handlers to ensure consistent behavior
• Maintains vertical scrollbar visibility logic while preventing unwanted row selection
• Ensures scrollbar handles and tracks are properly disabled from selection events

_{💡 (2/5) Greptile learns from your feedback when you react with 👍/👎!}

_{1 file(s) reviewed, no comment(s)
Edit PR Review Bot Settings | Greptile}

[ehconitin]

@aaryan182 thanks for the PR but I am pretty sure this was fixed in #9753
I couldn't reproduce the bug, can you?

[aaryan182]

@ehconitin Thank you for reviewing my PR. I understand that PR #9753 addressed scrollbar issue. I was able to reproduce the issue .

The current implementation correctly applies data-select-disable="True" to scrollbar tracks , however it doesn't apply this attribute to scrollbar handles which is what users interact with when scrolling.

My PR adds the missing attribute to handle elements which is different DOM element than the track .

The OverlayScrollbars library creates separate elements for tracks and handles and both need the data-select-disable attribute to prevent triggering selection.

[ehconitin]

@aaryan182 I've tried to reproduce this issue but wasn't able to trigger the selection while dragging the scrollbar handle.

Looking at the DOM structure and event handling, the handle element is nested inside the track:

<div class="os-scrollbar-track"> <!-- has data-select-disable="true" -->
<div class="os-scrollbar-handle"> <!-- child element -->
</div>
</div>

Since the handle is inside the track, and any selection events would bubble up through the DOM tree, the data-select-disable="true" on the track should already prevent selection when interacting with the handle.

Could you please:

1. Share specific steps to reproduce the issue
2. Include which browser and OS you're using
3. Provide a screen recording demonstrating the problem

This would help us understand if there's an edge case where the event bubbling isn't working as expected and validate if the additional attribute on the handle is necessary.

[aaryan182]

@ehconitin i again run using docker not happening now in brave browser and windows 11 os.
Its fixed it seems but I noticed that the selection behavior would sometimes still occur when dragging the handle particularly in certain browsers and when grabbing the handle from specific positions. This suggested to me that there might be a gap in the event propagation chain .