When clicking on an element in the Navigator, the Navigation toolbar pops up and its back and forth buttons dont seem to work correctly, so i'd prefer that this toolbar not appear and disrupt the position of the existing formatting toolbar and preferably be completely removed if the functionality of the buttons cant be clearly understood.
Raised in bug 38781 comment 10 and we should keep it there IMHO. *** This bug has been marked as a duplicate of bug 38781 ***
Jay was right, we better have an extra ticket for the UX issue. Discussion so far on bug 38782: (In reply to Olivier Hallot from comment #10) > Behaviour is apparently erratic and lack of description does not help user. > > https://ask.libreoffice.org/en/question/114955/navigation-toolbar-appears-on-inserting-headerfooter-in-a-document/ (In reply to Heiko Tietze from comment #11) > Introduced with bug 32869 in > https://opengrok.libreoffice.org/xref/core/sw/source/uibase/wrtsh/navmgr.cxx > the purpose is to navigate over hyperlinks in the document. We could enhance > the toolbar with next/previous page. (In reply to V Stuart Foote from comment #13) > The source [1][2] is reasonably well documented. And the Greenberg & > Cockburn [3] "recency with temporal ordering" based back and forward history > navigation remains. But, if fully functional would expect the feature to be > less about navigating hyperlinks (internal or external) and for the control > to provide more generic Back and Forward movements within a document. > > A GoToMark, GoToFLy, GotoINetAttr, GotoOutline (index), GotoOutline > (string), GotoRegion, GotoRefMark, GotoNextTOXBase, GotoTable,GotoFld, and > GotoRedline action were linked as history navigation targets. > > Unfortunately, not clear the "recency with temporal ordering" of the > navigation history is still implemented correctly. I couldn't identify where > in UI a user could "add" a mark to trigger inclusion of a SwUnoCsr position > to the m_entries[] list and _activate_ the control. And while inserting an > internal hyperlink--reference, bookmark, header, footer, etc. the Cusor is > registered into the navigation history, and activates the Navigation toolbar > controls--other actions for cursor/focus movement do not. For example a > Go-to-End of document should provide a Navigation toolbar action to return > from. > > =-ref-= > [1] > https://opengrok.libreoffice.org/xref/core/sw/source/uibase/wrtsh/navmgr. > cxx?a=true > > [2] https://opengrok.libreoffice.org/xref/core/sw/source/uibase/inc/navsh.hxx > > [3] https://prism.ucalgary.ca/bitstream/handle/1880/45977/1999-641-04.pdf (In reply to V Stuart Foote from comment #14) > Aslo, if fully functional seems like this set of controls--.uno:NavigateBack > & .uno:NavigateForward would make sense to appear in the Standard toolbar, > or maybe the Navigator dialog adjacent to the PreviousPage/NextPage buttons.
(In reply to Heiko Tietze from comment #2) > Jay was right, we better have an extra ticket for the UX issue. Sorry I should also have included link to the navmgr.hxx. Here is Maja's original description of the navigation history. When originaly implemented the function tracked SwPosition--but Michael S. changed that to use SwUnoCrsr (unocrsr.hxx) for more robust behavior [1]: class SW_DLLPUBLIC SwNavigationMgr { private: /* * List of entries in the navigation history * Each entry is a SwPosition, which represents a position within the document * SwPosition is given by a node index (SwNodeIndex) which usually represents the paragraph the position is in * and an index (SwIndex), which represents the position inside this paragraph. * You can find more on SwPositions at http://wiki.services.openoffice.org/wiki/Writer_Core_And_Layout * * The navigation history behaves as a stack, to which items are added when we jump to a new position * (e.g. click a link, or double click an entry from the navigator). * Every use of the back/forward buttons results in moving the stack pointer within the navigation history */ So, it seems the Navigation toolbar is a dedicated shell for Writer that tracks movement through the UI and permits "back" button navigation of its stack with some concept of "curency" of position in the history of movements. Provides a helper in addition to other Navigator's by "mode" provided movements. For example the "reminder" mode (the Paper clip icon) keeps a separate stack of Marks (to depth of MAX_MARKS default of 5)--but the NavigationMgr m_aNavigationMgr receives and follows these swUnoCursr objects on its stack. The modes provided in Navigator are specific for each flavor of events. IIUC the NavigationMgr exposes the movement events (that it is aware of) [2]--and implements a toolbar with Back/Forward button controls to move among all of them. I think the buttons from the toolbar probably ought to have been added to the Navigator from the beginning. The Navigator's current Previous/Next buttons apply to the active Navigator mode--while the Navigation buttons draw events from across the UI. Is there a spot on the Navigator UI the more general movements from the Navigation toolbar would make sense? Likewise I think some of the movements in the sw UI ought to be exposed to the Navigation toolbar's buttons but aren't--position to Top of document, End of document, next Paragraph, next page, etc. This may need some additional dev effort to Also, seems the same ability to navigate between cursor positions in the other LO modules by Back/Forward button action would be a good enhancement if this is the right framework to hang it off of. =-ref-= [1] https://opengrok.libreoffice.org/xref/core/sw/source/uibase/inc/navmgr.hxx?#24 [2] https://opengrok.libreoffice.org/xref/core/sw/source/uibase/inc/wrtsh.hxx?#461
The Navigation toolbar is a counterpoint to the modal "Navigator", as intended its backward and forward navigation was to be more like navigating a web browser's history, positioning document focus to any of the established markers. The use case is still valid, but not sure the implementation is fully complete, and no documentation was added to help (bug 38781). Kind of think that if this were fully developed, it would be a reasonable interface to allow history movement between soffice.bin modules rather than just the Writer shell, where as noted it is a bit confusing as to function.
(In reply to V Stuart Foote from comment #4) > The use case is still valid, but not sure the implementation is fully > complete, and no documentation was added to help (bug 38781). Indeed. So better improve then remove
@Maxim, Adolfo -- does this UI navigation stack make sense to retain? That is, is it worth salvaging? And given it was a GSOC (2009 so OOo) effort would be sad to just purge it. See the OOo history for the feature request: https://bz.apache.org/ooo/show_bug.cgi?id=5608
@Thorsten, you mentored Maja D. in 2009 for this work--do you have any thoughts on what is correct here in these dark corners of the code base?
(In reply to V Stuart Foote from comment #7) > @Thorsten, you mentored Maja D. in 2009 for this work--do you have any > thoughts on what is correct here in these dark corners of the code base? If the toolbar is the problem - move the functions somewhere else? At least when it was implemented, people thought it's quite useful.
I one had a patch to remove this very feature at https://gerrit.libreoffice.org/#/c/10551/ but there were some people opposing the removal. So it seems to be useful to some. Of course we should make sure the toolbar doesn't randomly pops up etc.
Removing needsUX as the decision was made to keep the functionality. As Samuel points out we have top take care about the position of the controls; should be done in this ticket IMO.
As an idea, it was suggested to work these functions into the Navigator dialog (good idea IMO) or/and added to Standard toolbar (very bad idea IMO). Fix docking left (edit: or anywhere else), another idea, is not an option since users define the UI and have the Navigator docked left, for example.
(In reply to Heiko Tietze from comment #11) > As an idea, it was suggested to work these functions into the Navigator > dialog (good idea IMO) The tool bar of the Navigator already is quite loaded, so I see a challenge there.. Integrating in the Navigation bar, that can be started from the Navigator? Could be. But will then the 'edit positions' be on of the many choices, or a separate one?
*** Bug 98762 has been marked as a duplicate of this bug. ***
*** Bug 98877 has been marked as a duplicate of this bug. ***
*** Bug 49710 has been marked as a duplicate of this bug. ***
*** Bug 43220 has been marked as a duplicate of this bug. ***
QA housekeeping, moved all issues of the Navigation toolbar here. Either need to complete the implementation of the multi-element type navigation stack fixing its behavior (in GUI and function); or go ahead and delete the module. This was developed at the end of OOo era, and integrated into LibreOffice at initial 3.3.0 release.
Created attachment 142262 [details] Renewal of navigation toolbar It proposes a reduced version of the current 'Reminder' function of LO Writer to replace the Navigation toolbar.
Created attachment 142560 [details] replace the navigation facility by a more straightforward function
I am disappointed that the bug pointed out by Yousuf (the ever-popping up navigation bar) has not been removed even in the newest version of LO (6.0.6.2). Maybe some people have a narrow notion of 'bug' so that something is a bug only if the entire system breaks down. Please widen the notion a bit: Something that definitely obstructs the user in doing his work is a bug. If you really think the navigation bar is a valuable feature, then at least allow the user to deactivate it. Maybe progress on this matter presupposes that somebody change the status to 'confirmed'.
(In reply to Christian Lehmann from comment #20) > I am disappointed that the bug pointed out by Yousuf (the ever-popping up > navigation bar) has not been removed even in the newest version of LO > (6.0.6.2). Maybe some people have a narrow notion of 'bug' so that something > is a bug only if the entire system breaks down. Please widen the notion a > bit: Something that definitely obstructs the user in doing his work is a > bug. If you really think the navigation bar is a valuable feature, then at > least allow the user to deactivate it. > > Maybe progress on this matter presupposes that somebody change the status to > 'confirmed'. I haven't notice Navigation bar in Lo 6.1 with Notebookbar Style, but I don't think this bug will be solved... you just learn to live with it. I removed all buttons on this toolbar (so it is very small) and position it at the top left part of my screen, so when it appears, it does not make me nervous too much... I hardly notice it :-) Per each session, you can also go to View -> Toolbars -> Navigation to disable it temporarily. So during that session, it will not popup. Next time, you just need to do the same. So these are workarounds that can help you to reduce the pain caused by this bug.
@Ljiljan: Not even the workarounds that you recommend do what you think. If you deactivate the navigator, it pops up again on the next (unpredictable) occasion, not just when I start LO the next time. And it does occupy an entire line of precious writing space. The navigator icon is the only icon in the entire LO software that - occupies an entire toolbar by itself - and the user is not allowed to deactivate this toolbar for the entire session (or forever). It must really enjoy the highest priority in the view of some developers.
(In reply to Christian Lehmann from comment #22) > The navigator icon is the only icon in the entire LO software that > - occupies an entire toolbar by itself > - and the user is not allowed to deactivate this toolbar for the entire > session (or forever). As you can read in the comments. it's not only you that is annoyed by the behavior. Let's ask UX_advise to come with a choice on how to resolve.
(In reply to Christian Lehmann from comment #22) > ... > The navigator icon is the only icon in the entire LO software that > - occupies an entire toolbar by itself > - and the user is not allowed to deactivate this toolbar for the entire > session (or forever). > It must really enjoy the highest priority in the view of some developers. The control is the "Navigation" toolbar, the Navigator is a completely different dialog based UI component. Otherwise, the Navigation toolbar *is* a standard toolbar and behaves as such. Meaning "just dock it", IMHO at the end of the Standard toolbar is pretty unobtrusive. Positioned there its two buttons are well behaved. It would be great to complete multi-element navigation, especially cross module. Or if concensus is to kill it off for lack of dev interest that works also. Otherwise, it really is benign, and seems to have no impact with the MUFFIN Notebookbar as the popup toolbars are suppressed. It is only its default toolbar pop-up behavior that annoys folks--that seems an easy fix (users can open and dock it, or we can pick a spot and do it by default).
(In reply to Samuel Mehrbrodt (CIB) from comment #9) > So it seems to be useful to some. Of course we should make sure the toolbar > doesn't randomly pops up etc. I fully agree with this opinion
We talked about this in the design meeting and suggest to dock by default at the end of the Standard toolbar (as there is one item more space than on the Formatting toolbar).
Created attachment 148536 [details] Docked Navigator in Writer, Calc and Navigation Toolbar Please see the attached image. I use the Navigator docked in the sidebar, in both Writer & Calc. I have more horizontal space than vertical, so I add things to the left or right. I dock everything when available. I don't use the Navigation Toolbar (1), because I use the Navigator scrollable list. It seems the main purpose of the Navigation Toolbar is to prime the left and right arrows on the Navigator (or the up & down arrows in the Navigation Toolbar). The "Extended Help" text changes over the Navigator left and right arrows to reflect what was selected in the Navigation Toolbar. Suggestion 1: How about changing how the button works in the Navigator. When clicked, rather than opening the Navigation Toolbar, change the button to a drop-down radio list, similar to (2) and (3). Change the button image to reflect the action being taken; Reuse the images that are currently shown on the Navigation Toolbar. The arrows in the Navigator can then be used to reposition. To change what to maneuver to, just click the Navigation button on the Navigator and select a different radio button. Suggestion 2: Remove the button, and instead use whatever is highlighted/selected in the Navigator list to prime the arrows. For example, if the user clicks on "Images" the arrows would find the previous and next images.
(In reply to russell from comment #27) > How about changing how the button works in the Navigator... > ... > Remove the button, and instead use whatever is highlighted/selected in the > Navigator list to prime the arrows. Of course there are better solutions. For example we made a fancy mockup for the Navigator https://design.blog.documentfoundation.org/2016/07/31/how-the-navigator-may-support-object-handling-in-libreoffice-draw/ but due to lack of development expertise (and the need for effort in other areas) it's far from being implemented. Docking is simple and can be done by (almost) everyone, that's why we recommend it.
(In reply to russell from comment #27) > > I don't use the Navigation Toolbar (1), because I use the Navigator > scrollable list. > And that is not the "Navigation Toolbar" feature this issue is about. That is the "mode selector" for the modal Navigator deck of the Sidebar. Issue here is the pop-up behavior of the incomplete multi-mode Navigation stack of the toolbar, nothing to do with the Navigator deck (ex dialog). They happen to be similarly named, but completely different function and code.
RE: the "just dock it" suggestion That doesn't really fix the problem for me, because I normally work without the standard toolbar visible. (Everything I need to do in a word processor I can do with keyboard shortcuts, other than disable the navigation toolbar.) I would say this is the single biggest user irritation about LibreOffice for me, other than the occasional crash. Would it be really easy to not have the navigation toolbar pop up when someone adds a footnote? That wouldn't require getting rid of the toolbar. Just don't let it force itself on users.
(In reply to Pierce Randall from comment #30) > > Would it be really easy to not have the navigation toolbar pop up when > someone adds a footnote? That wouldn't require getting rid of the toolbar. > Just don't let it force itself on users. I agree. I use footnotes *all* the time, but I've never once needed a toolbar to navigate between them. Why can I control exactly what my toolbars look like except in this one odd (and useless) case? It just adds clutter. My partial solution is just to dock the navigation bar next the standard one, but it's still annoying when the toolbar appears in the blank space when I add a note in a new session (and I even did what Ljiljan above did: removed all the icons from the bar so it's just the toolbar handle that appears!). Again, just more clutter.
*** Bug 137037 has been marked as a duplicate of this bug. ***
*** Bug 124486 has been marked as a duplicate of this bug. ***
This is extremely annoying issue, especially when using tabbed toolbar layout (so you can't just pin the toolbar next to other toolbar). Hopefully there will be some progress on this!
@Jim, given the functional relationship of the Navigation Stack here to the Find bar/Navigator modal navigation is it feasible to eliminate the contextual toolbar and merge the navigation stack into the Navigator? see comment 2 comment 3 That would be in addition to the Navigator current modal find (forward/backward) that you and Caolán cleaned up with the Find bar logic. The pop-up contextual Navigation toolbar is tamed by appending to the Standard toolbar, but continued contextual pop-up is a problem for the other UI modes. Also the objects added to its multi-mode navigation stack seem to need a tweak--e.g. bug 54412 and bug 74604
Created attachment 168446 [details] Use navigate back and forward from Navigate By controls In this demo I have disabled the Navigation tool bar from appearing when 'Go to' heading moves are done by double clicking heading entries in the content tree in the Navigator. 'Navigate' entry has been added to the 'Navigate By' drop down control, and when selected, scroll to previous and next controls will navigate back and forward the same as the buttons do in the Navigation tool bar. @Stuart, This seems to track with your idea, right?
(In reply to Jim Raykowski from comment #37) > Created attachment 168446 [details] >... > > @Stuart, This seems to track with your idea, right? Yes, spot on! Toolbar would be made non-popup? And, could the navmgr.cxx [1][2] navigation stack entries be expanded to include other positional markers "cursors"--e.g. home, end, next/prev page, para, sentence when used? But, may need UX input for the lb name (I know you probably reused the .uno:NavigateBack, .uno:NavigateForward controls). But Navigate by 'Navigate' will cause whiplash. Perhaps 'Multi-modal', or maybe 'RCTO' ("recency with temporal ordering")? =-ref-= [1] https://opengrok.libreoffice.org/xref/core/sw/source/uibase/wrtsh/navmgr.cxx [2] https://opengrok.libreoffice.org/xref/core/sw/source/uibase/inc/navmgr.hxx
Created attachment 168498 [details] Demo of Recency addition to Navigate By Here is a patch that adds Recency to Navigate By and removes the Navigation tool bar from appearing when entries are added to the navigation stack. The patch does not make any improvements on how the navigation stack is added to it only adds the ability to do Navigation tool bar type back and forward navigation using the scroll previous and next controls when Recency is selected in Navigate By. https://gerrit.libreoffice.org/c/core/+/108316
(In reply to Jim Raykowski from comment #39) > Created attachment 168498 [details] > Demo of Recency addition to Navigate By > > Here is a patch that adds Recency to Navigate By and removes the Navigation > tool bar from appearing when entries are added to the navigation stack. The > patch does not make any improvements on how the navigation stack is added to > it only adds the ability to do Navigation tool bar type back and forward > navigation using the scroll previous and next controls when Recency is > selected in Navigate By. > > https://gerrit.libreoffice.org/c/core/+/108316 Very nice! And while not shown in Jim's demo, the new 'Recency' mode in the Navigator would not be limited to just the Headings as shown. The navigation can be between cursor position of other types acted upon while working. E.g. you could drop 'Reminder's or 'Bookmark's into the mix and move between them efficiently. And eliminating the contextual pop-up of the 'Navigation toolbar' will improve a long present UX annoyance.
Here is effort to help improve the recency navigation feature by including additional cursor movements in the recency stack: https://gerrit.libreoffice.org/c/core/+/108529
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9f9798f07f0b56ae474f31ded671cc8da598d244 tdf#115817 Add navigation recency to Navigate By It will be available in 7.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.
Here is a list of actions implemented in comment 41 patch that add the current cursor position to the navigation stack. - Mouse button clicks that move the cursor to another position in the document - Searches that move the cursor - UNO commands that move the cursor to another position in the document: .uno:GoToStartOfLine .uno:GoToEndOfLine .uno:StartOfLineSel .uno:EndOfLineSel .uno:GoToStartOfDoc .uno:GoToEndOfDoc .uno:StartOfDocumentSel .uno:EndOfDocumentSel .uno:SelectWord .uno:SelectSentence .uno:SelectAll .uno:GoToStartOfNextPage .uno:GoToEndOfNextPage .uno:GoToStartOfNextPageSel .uno:GoToEndOfNextPageSel .uno:GoToStartOfPrevPage .uno:GoToStartOfPrevPageSel .uno:GoToEndOfPrevPage .uno:GoToEndOfPrevPageSel .uno:GoToStartOfPage .uno:GoToStartOfPageSel .uno:GoToEndOfPage .uno:GoToEndOfPageSel .uno:GoToStartOfColumn .uno:GoToEndOfColumn .uno:GoToStartOfNextColumn .uno:GoToEndOfNextColumn .uno:GoToStartOfPrevColumn .uno:GoToEndOfPrevColumn .uno:GoToNextWord .uno:WordRightSel .uno:GoToPrevWord .uno:WordLefttSel .uno:GoToStartOfPara .uno:StartOfParaSel .uno:GoToEndOfPara .uno:EndOfParaSel .uno:GotoNextSentence .uno:GotoNextSentenceSel .uno:GotoPrevSentence .uno:GotoPrevSentenceSel .uno:GoToNextPara .uno:GoToPrevPara .uno:ToggleControlFocus - moves to nearest control in document .uno:JumpToNextFrame .uno:JumpToNextFootnote .uno:JumpToPrevFootnote .uno:JumpToHeader .uno:JumpToFooter .uno:JumpToFootnoteOrAnchor .uno:JumpToFootnoteArea .uno:JumpToPrevTable .uno:JumpToNextTable .uno:JumpToNextRegion .uno:JumpToPrevRegion .uno:GotoNextIndexMark .uno:GotoPrevIndexMark .uno:GotoNextTableFormula .uno:GotoNextWrongTableFormula .uno:GotoPrevTableFormula .uno:GotoPrevWrongTableFormula
Version: 7.2.0.0.alpha0+ (x64) Build ID: 9f9798f07f0b56ae474f31ded671cc8da598d244 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded @Jim, got a first look at the rework today Very preliminary, but noticed Recency seems to clear out the navigation stack when a specific mode change is made on the Navigator and then returning to Recency. E.g., was trying to drop 'Reminder' marks following some cursor jumps. They don't seem to make it onto the stack until I switch to Reminder mode, where mode navigation is fine, but when back to Recency--just the 'Reminders' remain, the other cursor jumps have been cleared.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/50678a771daa6cd5d3414c25930761c65aab4244 tdf#115817 add places that add current position to navigation manager It will be available in 7.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.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/cf98f078b0a4e8c36cf0579042442e5583013608 tdf#115817 set standard mode before recency navigation It will be available in 7.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.
(In reply to Commit Notification from comment #45) > Jim Raykowski committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/ > 50678a771daa6cd5d3414c25930761c65aab4244 @Jim, cursor navigation is working great now! Into and out of the other Navigator modes, navigation stack remains intact and the Greenberg & Cockburn "recency with temporal ordering" is behaving like it is supposed to. The Navigation TB is nicely suppressed now. But when opened, it immediately tracks the stack the same as the 'Recency' mode in Navigator. Sidebar, do you think we'd need a way for user to reset and force clear the navmgr stack during an edit session? Or just as now where a save, close and reopen is enough to reset? =-testing-= TB777 nightly 2021-01-18 Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 1a167625314bf36b735176ed488e6ba9b5e9b675 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded @Jim, as I finished this I saw you had to tweak things with https://gerrit.libreoffice.org/c/core/+/109504, hope it still works as well with navigate back and navigate forward controls. If it rolls tomorrow I'll be able to compare.
(In reply to V Stuart Foote from comment #47) > The Navigation TB is nicely suppressed now. But when opened, it immediately > tracks the stack the same as the 'Recency' mode in Navigator. > Noticed that Navigation toolbar doesn't reappear if it was in the toolbar layout at exit. Patch is in progress of being approved by Jenkins. > Sidebar, do you think we'd need a way for user to reset and force clear the > navmgr stack during an edit session? Or just as now where a save, close and > reopen is enough to reset? We could add an UNO command to do this. FWIW, I never want the recency stack to clear in the ide I use, but it does and I'm not sure why :( Maybe if it didn't, I would want a way to clear it :) > @Jim, as I finished this I saw you had to tweak things with > https://gerrit.libreoffice.org/c/core/+/109504, hope it still works as well > with navigate back and navigate forward controls. If it rolls tomorrow I'll > be able to compare. The patch fixes a bug when back navigation is done from a drawing object. It can be seen using the Navigation toolbar back button. It does not happen when using the Navigate-by Recency back button.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/23746af5b76d55ce781c8b9b58bfd566805b14ed tdf#115817 Make the Navigation toolbar persist It will be available in 7.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.
Is this bug fixed? If some aspects are still TODO, it would be nice to document that if this bug is left open.
This should have been closed out with new BZ issues opened against the Recency mode of Navigator SB deck for Writer.
*** Bug 36449 has been marked as a duplicate of this bug. ***