Description: When the Navigator is first displayed, Navigate by Page is shown by default. In earlier LO versions, the user's last choice had been remembered and was shown at start. The user now chooses 'Navigate by Recency' from the combo menu. At its right side, up and down arrowheads should appear. Instead, a page number stays there, so no navigation by recency is possible. This only changes with the first Save or AutoRecovery of the file. Steps to Reproduce: 1. Load a document into Writer. 2. Press F5. 3. In the combo menu of the Navigation bar, choose 'Navigate by recency'. Actual Results: 'Recency' stands, but the page number at its right side, stemming from 'Navigate by Page', remains. Consequently, one cannot navigate by recency. Expected Results: Upward and downward arrow heads should appear. Reproducible: Always User Profile Reset: No Additional Info: This is a new bug in LO 24. It did not exist up to and including version 7.
Confirmed. Noticed this while looking at bug 164733 regards the 'Reminder' mode. The "Navigate by" toggle between the 'Page' spinbox and the other by-mode previous/go-back next/go-forward "arrows" do not activate when changing the selected mode. Likewise when coming from a different mode and selecting the 'Page' mode, the spinbox for go to page do not reappear. IIRC both did when https://gerrit.libreoffice.org/c/core/+/163723 was put in for bug 140448 So not applicable at 24.2 release branch (which still has the dedicated movement arrows) but is present in 24.8.4 and current master against 25.8.0. But, I find that if I fully close the SB deck and tabbar, then reopen both, the widget will refresh to the correct mode. No need to save/close the document. Likewise the linked Find bar controls (first expose their visible buttons) behave in similar fashion, with a close/reopen of the bar needed to reset the mode's movement buttons (just absent the page mode's spinbox). Once into the mode fully (i.e. the movement arrows get labels appropriate for the mode) they work as expected. It is just the changes between modes that get hung up. @Jim, could you have a look. =-testing-= Version: 24.8.4.2 (X86_64) / LibreOffice Community Build ID: bb3cfa12c7b1bf994ecc5649a80400d06cd71002 CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 35b9371acf5a1295ef7c12bbfa285efb7ea4b485 CPU threads: 8; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
My bibisect effort resulted in the following commit as the change in behavior: commit 288d720e4940d8fdd71715e6d339765e90716931 Author: Armin Le Grand (allotropia) <armin.le.grand.extern@allotropia.de> Date: Thu Oct 31 13:38:30 2024 +0100 (3 months ago) Done to fix Bug 162666 - UI: Styles panel - Scrolling to bottom and/or top of style list is hard with multiple table cells selected: list always jumps back to active style. I used the bibisect repository found here: https://bibisect.libreoffice.org/linux-64-25.2
Could you please check if this still happens after my fix to https://bugs.documentfoundation.org/show_bug.cgi?id=164476? Note that you need a pretty current master, just commited that one. Also might be of interest: you might use 'DISABLE_SYSTEM_DEPENDENT_PRIMITIVE_RENDERER=1' as EnvVar to start the office, that suppresses CairoSDPR wihout needing another build -> if error is gone, it may have to do with CairoSDPR changes. Thanks for support and HTH!
(In reply to Armin Le Grand (allotropia) from comment #3) > Could you please check if this still happens after my fix to @Armin, Unfortunately still the same annoyance. On the SideBar Navigator's deck a change of the 'Navigate by' lb selection is still not effecting a change from the 'Go to page' spin box over to the navigate modes 'Previous|Next' buttons. The change to mode is fully effected if I fully close the SideBar Deck and relaunch from main View menu, or with its <Ctrl>+F5 shortcut. Also, noticed that after a relaunch of the SideBar selecting a different Navigate by mode does not refresh the 'Previous|Next' or 'Go Back|Go Forward' movement buttons for the mode. Fully closing and relaunching the SideBar deck is needed there as well. =-testing-= 2025-02-02 TB77 nightly build Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 08e40accb3fabe676746c40797efc20eaa218801 CPU threads: 8; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Also affecting the Quick Find bar. Note the button labels for the linked Navigate by mode when exposed (selected on the QFB 'Visible Buttons' context menu) also require the SideBar deck to be fully closed and relaunched to effect a change into the correct labeling.
Thanks for checking and the additional infos!
On it - checking why there is no update anymore. It must be related to SfxStateCache. I *thought* I had understand that piece of code, but maybe (still) not ...
First idea was that the two 'special' items INVALID_POOL_ITEM/DISABLED_POOL_ITEM use the same item class and comparing them may say true for INVALID_POOL_ITEM == DISABLED_POOL_ITEM, but that's not it. Still a danger that needs to be eliminated...
Think I found and corrected it in SfxStateCache (still complicated), see https://gerrit.libreoffice.org/c/core/+/181194
Armin Le Grand (Collabora) committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6042e60d69c40d1f307710e60a278cb286d68603 tdf#164745 fix SfxStateCache It will be available in 25.8.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.
@Armin, I tested with: Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 6042e60d69c40d1f307710e60a278cb286d68603 CPU threads: 2; OS: Linux 6.8; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded For me, the Navigate-By control in the Navigator now works as expected.
Confirm, the Navigate by modes in Navigator and the Quick Find Bar are behaving again in master against 25.8.0 Can see the patch for 25.2 is in works (https://gerrit.libreoffice.org/c/core/+/181229) Will there be a backport for 24.8, or too late in the release cycle? =-testing-= 2025-02-07 TB77 nightly Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 6042e60d69c40d1f307710e60a278cb286d68603 CPU threads: 8; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Armin Le Grand (Collabora) committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/04693b1b6e54de341e82bab0455be340dd0fceb0 tdf#164745 fix SfxStateCache It will be available in 25.2.2. 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.