-
Notifications
You must be signed in to change notification settings - Fork 16.3k
Fix text selection jumping in logs pane to match text editor behavior #57309
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix text selection jumping in logs pane to match text editor behavior #57309
Conversation
When selecting text by clicking and dragging in the logs pane, the selection would jump unexpectedly when clicking in empty space at the end of lines or below the last log line. This was caused by the virtualized list rendering with absolutely positioned elements that didn't extend to fill available space. Changes: - Make log line containers full width to enable selection in empty areas - Add invisible filler element below last log line to prevent EOF jump - Ensure minimum height covers all empty space at bottom of container The logs pane now behaves like traditional text editors (e.g. Notepad) where users can click anywhere and drag to select multiple lines without the selection jumping.
|
@kaxil Can we include this bugfix in 3.1.2 ? |
|
Marked as 3.1.2 -> If we merge it and it will be easy to cherry-pick, it will be good to go. |
jscheffl
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Requesting another pair of eyes with CSS knowledge - looks like a reasonable fix as a noob review.
Actually was close to hit the approve button but making a manual test found the following:
Test via Chrome looks good!
https://github.com/user-attachments/assets/8476dbf1-dba8-491a-a25f-dab4ee1b3c99
Test in Firefox still shows some problem - not sure whether Firefox needs some other tweaking?
https://github.com/user-attachments/assets/052108d9-9220-4416-9b57-c694ea7381f1
...and this would be maybe at least a 50% solution but I assume the 100% line width breaks the "line wrap" mode, see recorded video at the end, if you turn on line wrapping then no logs are displayed at all. At least this needs some rework.
When toggling text wrap on in the logs pane, all log content would
disappear. This was caused by three issues:
1. CSS textWrap property was set to pre instead of pre-wrap, which
preserves whitespace but does not wrap text
2. Virtualizer was not remeasuring items when wrap toggled, causing
items to be positioned with cached single-line heights even when
text became multi-line
3. Width constraints conflicted - items need to be constrained to 100%
when wrapped (to force wrapping) but max-content when unwrapped
(to allow horizontal scrolling)
Changes:
- Change textWrap from pre to pre-wrap when wrap is enabled
- Add useLayoutEffect to force virtualizer remeasurement on wrap toggle
- Add width=100% to VStack to provide proper width reference
- Set item width conditionally: 100% when wrapped, max-content when not
- Keep minWidth=100% always for text selection in empty areas
|
@jscheffl , thanks for the manual test and catching the issue! Ive made some corrections and the logs view is working as expected. I also ran the same manual tests on edge, chrome, firefox and the seem consistent. Give it another shot? |
jscheffl
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works for me now - still a second pair of CSS capable eyes would be good.
A very very small nit is left but only in Firefox, seems that in Firefox there is a pixel padding / margin between the lines, if you hit this single pixel then it flickers. Not happening in Chrome as the distance between lines seems different there. But can be adressed in another PR as this is already 95,9%! Thanks
…tor behavior (#57309) * Fix text selection jumping in logs pane to match text editor behavior When selecting text by clicking and dragging in the logs pane, the selection would jump unexpectedly when clicking in empty space at the end of lines or below the last log line. This was caused by the virtualized list rendering with absolutely positioned elements that didn't extend to fill available space. Changes: - Make log line containers full width to enable selection in empty areas - Add invisible filler element below last log line to prevent EOF jump - Ensure minimum height covers all empty space at bottom of container The logs pane now behaves like traditional text editors (e.g. Notepad) where users can click anywhere and drag to select multiple lines without the selection jumping. * Fix log view vanishing when text wrap is enabled When toggling text wrap on in the logs pane, all log content would disappear. This was caused by three issues: 1. CSS textWrap property was set to pre instead of pre-wrap, which preserves whitespace but does not wrap text 2. Virtualizer was not remeasuring items when wrap toggled, causing items to be positioned with cached single-line heights even when text became multi-line 3. Width constraints conflicted - items need to be constrained to 100% when wrapped (to force wrapping) but max-content when unwrapped (to allow horizontal scrolling) Changes: - Change textWrap from pre to pre-wrap when wrap is enabled - Add useLayoutEffect to force virtualizer remeasurement on wrap toggle - Add width=100% to VStack to provide proper width reference - Set item width conditionally: 100% when wrapped, max-content when not - Keep minWidth=100% always for text selection in empty areas (cherry picked from commit d6fa3b0) Co-authored-by: Dheeraj Turaga <dheerajturaga@gmail.com>
@jscheffl @bbovenzi thanks for review and merge. Il dig into the nit in a different PR. Looks like its a very very small flicker which is largely unnoticeable and seems to only happen in Firefox |
Yes, my guess is there is 1px padding in FF and if you exactly hit this with the mouse then it is the same like the problem you fixed that you get over a "non log line" area==pixel. As well as in my FF I see a bit (1pixel?) more distance between the text lines, also if you select the text you see 1px distance between the lines which are filles in Chrome when selecting. |
…tor behavior (#57309) (#57453) * Fix text selection jumping in logs pane to match text editor behavior When selecting text by clicking and dragging in the logs pane, the selection would jump unexpectedly when clicking in empty space at the end of lines or below the last log line. This was caused by the virtualized list rendering with absolutely positioned elements that didn't extend to fill available space. Changes: - Make log line containers full width to enable selection in empty areas - Add invisible filler element below last log line to prevent EOF jump - Ensure minimum height covers all empty space at bottom of container The logs pane now behaves like traditional text editors (e.g. Notepad) where users can click anywhere and drag to select multiple lines without the selection jumping. * Fix log view vanishing when text wrap is enabled When toggling text wrap on in the logs pane, all log content would disappear. This was caused by three issues: 1. CSS textWrap property was set to pre instead of pre-wrap, which preserves whitespace but does not wrap text 2. Virtualizer was not remeasuring items when wrap toggled, causing items to be positioned with cached single-line heights even when text became multi-line 3. Width constraints conflicted - items need to be constrained to 100% when wrapped (to force wrapping) but max-content when unwrapped (to allow horizontal scrolling) Changes: - Change textWrap from pre to pre-wrap when wrap is enabled - Add useLayoutEffect to force virtualizer remeasurement on wrap toggle - Add width=100% to VStack to provide proper width reference - Set item width conditionally: 100% when wrapped, max-content when not - Keep minWidth=100% always for text selection in empty areas (cherry picked from commit d6fa3b0) Co-authored-by: Dheeraj Turaga <dheerajturaga@gmail.com>
…apache#57309) * Fix text selection jumping in logs pane to match text editor behavior When selecting text by clicking and dragging in the logs pane, the selection would jump unexpectedly when clicking in empty space at the end of lines or below the last log line. This was caused by the virtualized list rendering with absolutely positioned elements that didn't extend to fill available space. Changes: - Make log line containers full width to enable selection in empty areas - Add invisible filler element below last log line to prevent EOF jump - Ensure minimum height covers all empty space at bottom of container The logs pane now behaves like traditional text editors (e.g. Notepad) where users can click anywhere and drag to select multiple lines without the selection jumping. * Fix log view vanishing when text wrap is enabled When toggling text wrap on in the logs pane, all log content would disappear. This was caused by three issues: 1. CSS textWrap property was set to pre instead of pre-wrap, which preserves whitespace but does not wrap text 2. Virtualizer was not remeasuring items when wrap toggled, causing items to be positioned with cached single-line heights even when text became multi-line 3. Width constraints conflicted - items need to be constrained to 100% when wrapped (to force wrapping) but max-content when unwrapped (to allow horizontal scrolling) Changes: - Change textWrap from pre to pre-wrap when wrap is enabled - Add useLayoutEffect to force virtualizer remeasurement on wrap toggle - Add width=100% to VStack to provide proper width reference - Set item width conditionally: 100% when wrapped, max-content when not - Keep minWidth=100% always for text selection in empty areas
When selecting text by clicking and dragging in the logs pane, the
selection would jump unexpectedly when clicking in empty space at
the end of lines or below the last log line. This was caused by the
virtualized list rendering with absolutely positioned elements that
didn't extend to fill available space.
Changes:
The logs pane now behaves like traditional text editors (e.g. Notepad)
where users can click anywhere and drag to select multiple lines without
the selection jumping.
Before:
https://github.com/user-attachments/assets/6ee6aa15-90b7-42ec-b41e-2f3f2dcacf7f
After:
https://github.com/user-attachments/assets/42062183-d28c-4126-800a-45150c9cc1be