Skip to content

Conversation

@dheerajturaga
Copy link
Member

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.

Before:
https://github.com/user-attachments/assets/6ee6aa15-90b7-42ec-b41e-2f3f2dcacf7f

After:
https://github.com/user-attachments/assets/42062183-d28c-4126-800a-45150c9cc1be

  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.
@boring-cyborg boring-cyborg bot added the area:UI Related to UI/UX. For Frontend Developers. label Oct 26, 2025
@dheerajturaga
Copy link
Member Author

@kaxil Can we include this bugfix in 3.1.2 ?

@potiuk potiuk added this to the Airflow 3.1.2 milestone Oct 26, 2025
@potiuk
Copy link
Member

potiuk commented Oct 26, 2025

Marked as 3.1.2 -> If we merge it and it will be easy to cherry-pick, it will be good to go.

@potiuk potiuk added the backport-to-v3-1-test Mark PR with this label to backport to v3-1-test branch label Oct 26, 2025
Copy link
Contributor

@jscheffl jscheffl left a 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
@dheerajturaga
Copy link
Member Author

@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?

Copy link
Contributor

@jscheffl jscheffl left a 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

@jscheffl jscheffl merged commit d6fa3b0 into apache:main Oct 28, 2025
58 checks passed
github-actions bot pushed a commit that referenced this pull request Oct 28, 2025
…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>
@github-actions
Copy link

Backport successfully created: v3-1-test

Status Branch Result
v3-1-test PR Link

@dheerajturaga
Copy link
Member Author

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

@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

@jscheffl
Copy link
Contributor

@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.

jscheffl pushed a commit that referenced this pull request Oct 28, 2025
…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>
Lzzz666 pushed a commit to Lzzz666/airflow that referenced this pull request Oct 30, 2025
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:UI Related to UI/UX. For Frontend Developers. backport-to-v3-1-test Mark PR with this label to backport to v3-1-test branch

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants