Created attachment 183671 [details] Writer file showing bug involving display of headings in the Navigator. Version: 7.4.2.3 / LibreOffice Community Build ID: 382eef1f22670f7f4118c8c2dd222ec7ad009daf CPU threads: 2; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-GB (en_GB.UTF-8); UI: en-GB Calc: threaded 1. Open the attached writer doc. 2. Open the navigator. 3. Unfold one or more headings so that the subheadings are visible. 4. Close then reopen the navigator. ACTUAL RESULT: The outline collapses back so that only the top level of headings is visible. EXPECTED RESULT: The navigator should remember the lasts state of headings set by the user.
Similar type of issue reported in Bug 152115.
Confirmed, fully closing and reopening SB Navigator resets 'Headings' mode view to all collapsed. Note though that simply collapsing to SB Tab bar and expanding open in current session retains the Headings mode. Of course some folks prefer that behavior--clearing the Navigator with each use. So, not clear there is an issue here. But providing an option to retain state of the SB Navigator might be of use. Version: 7.4.2.3 (x64) / LibreOffice Community Build ID: 382eef1f22670f7f4118c8c2dd222ec7ad009daf CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
(In reply to R. Green from comment #0) I can't reproduce this with a 7.5 build: Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 2486d99c6053af1414117faac2c0db18c0d344c4 CPU threads: 4; OS: Linux 6.0; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US Also, for those trying to reproduce: Increase the maximum heading level represented in the Navigator to 4, otherwise you won't see any subheadings.
(In reply to Eyal Rozenberg from comment #3) > (In reply to R. Green from comment #0) > I can't reproduce this with a 7.5 build: Note: "Close then reopen" not just collapse the SB deck, please recheck. No issue if the SB deck is only collapsed and expanded. Only with a full close / open of the SB
Sounds like a lot of effort for not much benefit, IMO (remember per document the collapsed state of every single node meaning outline and other shown information). It would be nice to have a persistent tree state in general. But you don't get it anywhere else.
Not sure if the navigator sidebar deck is handled differently to the navigator dialog, but the two different things might introduce confusion here. I tested releases from 6.3 to 7.5. * Navigator sidebar deck: I tried folding the sidebar and closing the sidebar deck: the unfolding of the heading tree is persistent. Only closing the entire sidebar (with View > Sidebar, or Ctrl + F5) resets the heading tree. * View > Navigator (or F5): Closing the separate navigator window does lose the unfolding of the heading tree. R. Green does not mention the sidebar, so this report might only be about the separate dialog. I think the current behaviour of the sidebar might not need fixing (given that sidebar users will rarely close it but instead fold it out of the way, I assume). However, I can see users frustrated by losing it every time the Navigator window is closed. R. Green, can you please clarify? Versions: Version: 6.3.6.2 Build ID: 2196df99b074d8a661f4036fca8fa0cbfa33a497 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3; Locale: de-DE (en_AU.UTF-8); UI-Language: en-US Calc: threaded to Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: deb7bc82de19ea8e20c767fdf21f9ba4feb5e9f0 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
(In reply to Stéphane Guillou (stragu) from comment #6) > R. Green does not mention the sidebar, so this report might only be about > the separate dialog. I think the current behaviour of the sidebar might not > need fixing (given that sidebar users will rarely close it but instead fold > it out of the way, I assume). However, I can see users frustrated by losing > it every time the Navigator window is closed. > > R. Green, can you please clarify? I'm referrring to the free-floating navigator, not the sidebar one.
(In reply to R. Green from comment #7) > I'm referrring to the free-floating navigator, not the sidebar one. So don't close it? The floating Navigator (which is the same SB framework as the Navigator deck) is stateful and can be dragged out of the way on your desktop as you continue to work. Even onto another display if multi-headed. Exactly as the Sidebar Deck can now be collapsed to Tab bar or fully hidden out of the way. And closing either fully will clear the treeview, and I think that is appropriate default behavior. Doing more to hold full treeview status between launches of the Navigator in current session, or of pushing it out to MRU history in profile, would take some effort and likely be non-performant. Probably not worth any dev effort for the "temporary" Navigator--which goes away when we can finally undock decks (bug 85905). IMHO => WF
We discussed the topic in the design meeting. While I believe the effort is high I might be wrong. Remembering the collapsed state is welcome. So the question goes to the developers whether this option is hard to implement. (We discussed the request in respect to the sidebar; I guess the code and effort would be the same whether you close the floating F5/Navigator or the docked crt+F5/Sidebar.)
Here is effort that provides for same session restore of the Navigator headings outline expand state when the Navigator is closed and then reopened: https://gerrit.libreoffice.org/c/core/+/143326
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0da5631e08c17d1cb183b2249b0dfa0b6832ff9f tdf#152116 SwNavigator: Restore outline headings expand state It will be available in 7.5.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.
I can see it working in: Version: 7.5.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 7830ecc2e4e5dd264517c6554078fa807ff1fceb CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Thanks Jim! Some follow-up nitpicking: Should the view jump to the currently-select item too? At least in GTK3, it does not. "Hyperlink > Document > Target in document" does move the viewport to see the previously selected item.
(In reply to Stéphane Guillou (stragu) from comment #12) > I can see it working in: > Version: 7.5.0.0.alpha1+ (X86_64) / LibreOffice Community > Build ID: 7830ecc2e4e5dd264517c6554078fa807ff1fceb > CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 > Locale: en-AU (en_AU.UTF-8); UI: en-US > Calc: threaded Stéphane, Thanks for testing! > Some follow-up nitpicking: > > Should the view jump to the currently-select item too? At least in GTK3, it > does not. > "Hyperlink > Document > Target in document" does move the viewport to see > the previously selected item. I'm not certain it should be done. Best to open an enhancement ticket to get input from others.