A regression from 25.8, in recent masters against 26.2: Expanding the Formula Bar (inputwin) to its maximum 25 line height, movements by its scroll bar thumb and up/down buttons do not reposition the view port into text of the cell. Both the viewport and the text edit cursor remain fixed while the thumb repositions. Would expect the viewport to follow the thumb on the scroll bar--with or without edit cursor movement. Especially as moving the edit cursor (by keyboard up/down, or pgUp/pgDn) does move the view port and scrollbar thumb in sync. =-testing-= Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 6f68c46d0aa5fe872de0dec8777d35ff91886043 CPU threads: 28; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Created attachment 203342 [details] single cell spreadsheet with large text in cell Sample spreadsheet with a single cell holding a large text. Open in calc, and expand the Formula Bar (inputwin), movements using the thumb and the up/down buttons of the scrollbar seem disconnected from the text viewport or its edit cursor.
I can confirm with Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8ea8e254a3151f5390f3a10ff156fcaf8e7c5d5c CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded
This seems to have begun at the below commit in bibisect repository/OS linux-64-26.2. Adding Cc: to Caolán McNamara ; Could you possibly take a look at this one? Thanks 803ed3c1a8aa9ed662aa917cb5c8b0ece590e0ab is the first bad commit commit 803ed3c1a8aa9ed662aa917cb5c8b0ece590e0ab Author: Jenkins Build User <tdf@maggie.tdf> Date: Fri Aug 22 13:26:04 2025 +0200 source dfa2688357941d61765011cce0e511c9fd1f42a4 190050: gtk: Don't force redraw if "resize" didn't resize | https://gerrit.libreoffice.org/c/core/+/190050
The original bug has "... Windows 11 ..." but the code change itself identified as a regression is pure Linux/Gtk
@Heiko, could you poke at this a bit. Not clear this is only a gtk issue as bibisected.
The bisect could be identifying when the gtk version began to work like the gen version, by not triggering pseudo resize events when nothing really resized, maybe those were triggering scroll position updates as a side effect. That might fit with what was seen.
In sc/source/ui/app/inputwin.cxx ScTextWnd::DoScroll() calls m_xEditView->Scroll() with some reasonable value. This is passed through to ImpEditView::Scroll()... mpOutputWindow->Scroll(), where I stopped to dig into the code. This is beyond my skills.
Following that theory and bisecting with gen only enabled I get: commit a75ae98b11e0bf95d5d2cf30f8ed66f5cd1b3454 Author: Jenkins Build User <tdf@maggie.tdf> Date: Thu Aug 14 15:41:58 2025 +0200 source ec4da4667d7f948219d51daaf21cda8d5cd2f4ad commit ec4da4667d7f948219d51daaf21cda8d5cd2f4ad Author: Armin Le Grand (collabora) <Armin.LeGrand@collabora.com> Date: Wed Aug 13 19:45:13 2025 +0200 OutlinerView: Rework for standard selection visualization reverting this little hunk of editeng/source/editeng/impedit.cxx - if (comphelper::LibreOfficeKit::isActive()) + if (comphelper::LibreOfficeKit::isActive() || getEditViewCallbacks()) makes it behave (in both gen and gtk) as it did before.
https://gerrit.libreoffice.org/c/core/+/192775 makes this work, might be the right way to go
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f921a965c407677908e95fe99c3a430f832bdc43 Resolves: tdf#168870 scrolling input win doesn't redraw It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
That seems to fix this specific problem at least
(In reply to Caolán McNamara from comment #11) > That seems to fix this specific problem at least As always, thanks Caolán! Will give it a spin once TB77 rolls a nightly again.