#2416 SciTE doesn't maintain scroll position when switching tabs

[Piotr Fusik]

Environment:

• SciTE 5.4.0
• Windows 11 with latest updates
• 4K screen with 200% scale set in Windows

Steps:

• Open the attached scite-wrap-scroll.txt file in SciTE
• Select Options / Wrap
• Open any other tab (for example Ctrl+N)
• Scroll down in scite-wrap-scroll.txt so that line 10 is at the top
• Press Ctrl+Tab twice

Expected:

• File remains with line 10 at the top

Actual:

• File scrolled to line 7

This hinders working with files in wrap mode.
See the recording at https://www.youtube.com/watch?v=auWRXrE9zwE

[Neil Hodgson]

Most wrapping issues are due to wrapping occurring as a background task.

What is happening here is that SciTE switches to the document but has no wrapping. It tries to scroll to line 10 but that would leave lines beyond the document end appearing in the window. Therefore, it instead scrolls so that the end of the file is the last line in the window. In your case max_line - window_height_in_lines = 7 so it scrolls to line 7. After this, wrapping occurs as a background task with each portion of wrapping maintaining the top_line 7.

This will not occur if there are more than window_height_in_lines after your scroll position. The issue can be worked around by allowing display of whitespace after the file end with end.at.last.line=0.

[SilverDirk]

I'm having a similar issue, but shouldn't be affected by wrapping. I have SciTE 5.5.5 with Scintilla 5.5.5 compiled for GTK:3.24.49, on Arch Linux. Wrapping is enabled, but none of the lines in these files have wrapped.

An example: Starting from a file with 689 lines (physical lines, not wrapped) scrolled to look at lines 428-498 and with my cursor on line 485, I switch tabs to look at a file with 173 lines total. I scroll up to line 1 of the second tab and put the cursor on line 1. When I switch back to the original tab, it is viewing lines 103-173. Thankfully my cursor is still on 485 so touching an arrow key brings me back to where I left off, but it's still fairly annoying.

I added your workaround of end.at.last.line=0 and restarted SciTE and now I can scroll down until the final line of the file is at the top of the screen. Repeating the test, when I return to the first tab it is looking at 173-242 instead of 103-173.

And actually, I just turned off wrapping entirely and the problem persists.

[Neil Hodgson]

That appears to be a different and new problem. I have reproduced it on GTK/Linux but not on Windows. It may be related to the recent feature that remembers the selection and scroll position for undo.

[Neil Hodgson]

Likely caused by the fix to [#2322] where there were problems with updating scroll bars in some contexts. The fix deferred changing scroll bars to idle time. That means that the the scroll range hasn't been extended at the time setting the vertical scroll position is attempted so it is capped to the current range which is set to the number of lines in the previous file.

Potential fixes include narrowing the set of contexts where this deferral occurs. Perhaps the case where the application changes documents with SCI_GETDOCPOINTER can perform a synchronous change to the vertical scroll range since the application is likely to do that outside any other changes to the Scintilla widget. Since the above bug occurred on Xorg and hasn't been seen on Wayland, there could be a change to always update scroll bars synchronously on Wayland.

[Neil Hodgson]

Should check if Xorg or Wayland active.

Potential change for Wayland:

--- a/gtk/ScintillaGTK.cxx  Sun Apr 27 09:53:31 2025 +1000
+++ b/gtk/ScintillaGTK.cxx  Fri May 02 11:23:29 2025 +1000
@@ -1162,6 +1166,15 @@
 }

 void ScintillaGTK::SetScrollBars() {
+#if defined(GDK_WINDOWING_WAYLAND)

+   GdkDisplay *pdisplay = gdk_display_get_default();
+   if (GDK_IS_WAYLAND_DISPLAY(pdisplay)) {
+       // On Wayland, perform synchronous resize
+       ChangeScrollBars();
+       return;
+   }
+#endif
+
    if (scrollBarIdleID) {
        // Only allow one scroll bar change to be queued
        return;

[Neil Hodgson]

Committed change [9803ff] that, for GTK, synchronously resets the scroll bar to its full range inside SCI_SETDOCPOINTER. This fixes just the non-wrap case reported by SilverDirk above and not the initial wrap mode problem reported.

The above change for Wayland may help with other cases so may be applied in the future.