Problem description: I observed a strange behavior at the display of the Navigation toolbar in Writer. Perform the following steps in order to reproduce this strange behavior: [1] Open a new text document and insert some objects that are displayed in the Navigator (e.g. headings or tables). [2] Display the Navigator (F5) [3] Open the Navigation toolbar by clicking the icon at the top of the Navigator. -> [4a], [4b], [4c] or [4d] [4a] Click an item of the Navigation toolbar in order to select an object type. The object type is selected, BUT the Navigation toolbar is closed. In order to use the advantages (fast changes of object types, jump to next or previous item) of the Navigation toolbar, it has to be remained displayed. [4b] Click the Previous or Next Icon of the Navigation toolbar. A jump to the next or previous object is performed. But also here the toolbar is closed. Same disadvantages as [4a]. [4c] Close the Navigation toolbar by clicking the icon at the top of the Navigator (not on the X of the Navigation toolbar). The toolbar is closed. [4d] Click on the title bar of the Navigation toolbar and drag it to new position. -> [5a], [5b] or [5c] [5a] Click an item of the Navigation toolbar in order to select an object type. Now the toolbar remains displayed as expected for [4a]. [5b] Click the Previous or Next Icon of the Navigation toolbar. The jump is performed. Now the toolbar remains displayed as expected for [4b]. [5c] In order to close the Navigation toolbar click on the icon at the top of the Navigator (not at the X of the Navigation toolbar). The toolbar is not closed as expected but a second Navigation toolbar is displayed!! -> [6a] [6b] [6a] Move the second toolbar. The first toolbar disappears. [6b] Click on the Navigation icon below the vertical scroll bar. Expectation? The second toolbar is closed. The first toolbar remains displayed. -> [7] [7] Click again on the Navigation icon below the vertical scroll bar. Surprise: Toolbar No 3 is opened. The first toolbar remains displayed. -> [8] [8] Move the third toolbar to a new position. The first toolbar remains displayed. -> [9] [9] Click again on the Navigation icon below the vertical scroll bar. Toolbar No 4 is opened. Now there are 3 toolbars (No 1, 3, 4) displayed. Great! Really excellent conditions for navigation!? You can go on with moving, opening and closing of toolbars and jumping to previous or next positions, the effects are always equal or similar. Browser: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.24) Gecko/20111103 Firefox/3.6.24
reproduced on LibO 3.5.0 beta 1 on Fedora 64 bit steps from 1 to 5b (including) looks as useful features, but my be not documented beginning from 5c - bugs: 1) Navigation appear and disappear randomly (one time opens additional window and another time closes random existing window) 2) let we open document with several sections and several tables and open 2 window of Navigation. When press button "Table" on one window of Navigation and "Section" on another. On both windows appear buttons "To next section". Therefore no use of 2 windows of Navigation. I am not sure if it is bug or not fully implemented feature, therefore retain status as is.
I established as a bug the complete report. We can identify them as 1.- Navigation toolbar closes after selecting an object type to navigate. 2.- Several toolbars can be created after performing several times the actions described in the previous comments.
This is assigned since 2 years. Anything still happening? Harald, could you try reproducing this issue with a current LO version. Is it still valid?
Bug checked again with: Version 3.5.7 and 4.2.4: Bug still exists with the same behaviour. Version 4.3.3: Steps 1 to 6: Behaviour is equal as reported. Steps 7 to 9 are different, hence the navigation buttons have been moved from the vertical scroll bar to the Find Bar since version 4.3.0. But the new function is also not correct, see bug 79167. Hence strange behaviour still exists, set status back to NEW. Hope that's correct.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.4 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-12-20
I checked the bug again with version 5.0.4. The behaviour is a bit different bit it is still not correct. I observed the following: [1] Open a new text document and insert some objects that are displayed in the Navigator (e.g. headings or tables). [2] Display the Find toolbar (View > Toolbars > Find) [3] Display the Navigator (F5) [4] Open the Navigation toolbar by clicking the icon at the top of the Navigator. -> [5a], [5b], [5c] or [5d] [5a] Click an item of the Navigation toolbar in order to select an object type. The object type is selected, BUT the Navigation toolbar is closed. In order to use the advantages (fast changes of object types, jump to next or previous item) of the Navigation toolbar, it has to be remained displayed. [5b] Click the Previous or Next Icon of the Navigation toolbar. A jump to the next or previous object is performed. But also here the toolbar is closed. Same disadvantages as [5a]. [5c] Close the Navigation toolbar by clicking the icon at the top of the Navigator (not on the X of the Navigation toolbar). The toolbar is closed. [5d] Click on the title bar of the Navigation toolbar and drag it to new position. -> [6a], [6b] or [6c] [6a] Click an item of the Navigation toolbar in order to select an object type. Now the toolbar remains displayed as expected for [5a]. [6b] Click the Previous or Next Icon of the Navigation toolbar. The jump is performed. Now the toolbar remains displayed as expected for [5b]. [6c] In order to close the Navigation toolbar click on the icon at the top of the Navigator (not at the X of the Navigation toolbar). The toolbar is not closed as expected but a second Navigation toolbar is displayed!! -> [7a] [7b] [7a] Move the second toolbar. The first toolbar disappears. [7b] Click "Navigate by" in the find bar. Expectation? The second toolbar is closed. The first toolbar remains displayed. -> [8] [8] Click again "Navigate by" in the find bar. Another Toolbar is opened. The first toolbar disappears -> [9] [9] In order to close the Navigation toolbar click on the icon at the top of the Navigator (not at the X of the Navigation toolbar). The Navigation toolbar is not closed! ---- @Rafael: Do you work on this bug?
Bug still exists in version 5.3.2 with Win7. Bug already exists in version 3.3.0. Hence inherited from OOo.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Bug still exists with version 6.0.3 (64 bit, Win7). Steps 8 and 9 are different, because the Navigate By function has been changed meanwhile.
*** This bug has been marked as a duplicate of bug 115817 ***
This bug report does not treat the Navigation toolbar which is displayed with "View > Toolbars > Navigation" but by clicking the Navigation Symbol in the upper left corner of the Navigator window. The function of 'this' Navigator is described here: https://help.libreoffice.org/6.1/en-US/text/swriter/01/02110100.html Therefore this bug is not a dupe of bug 115817, which treats 'the other' Navigation toolbar. Hence I set back the status to NEW. Furthermore 'this' bug still exists in version 6.1.4. (64 bit, Win10)
(In reply to Harald Koester from comment #11) > This bug report does not treat the Navigation toolbar which is displayed > with "View > Toolbars > Navigation" but by clicking the Navigation Symbol in > the upper left corner of the Navigator window. The function of 'this' > Navigator is described here: > https://help.libreoffice.org/6.1/en-US/text/swriter/01/02110100.html > > Therefore this bug is not a dupe of bug 115817, which treats 'the other' > Navigation toolbar. Hence I set back the status to NEW. > Yes very sorry about that, duplicated in error. The Navigation toolbox (SWNavHelpToolbox) is a part of the Navigator dialog [1]--no relation to the Navigation Toolbar (SwNavigationMgr). > Furthermore 'this' bug still exists in version 6.1.4. (64 bit, Win10) Yes on 6.1.4 and current master/6.3.0 I do see the incorrect creation of more than one instance of the popup Toolbox if the toolbox object is moved, and then relaunched. There should only be one. As to making it persistent--imagine that can be done. @Caolán, Noel -- could you have a look at the life cycle of the toolbox =-ref-= [1] https://opengrok.libreoffice.org/xref/core/sw/source/uibase/inc/navipi.hxx?#47 [2] https://opengrok.libreoffice.org/xref/core/sw/source/uibase/utlui/navipi.cxx?#401
There's a whole bunch of stuff listed in here and much of it goes back to 2011 so it seems a potential tarpit. I see the multiple toolbox problem locally so I'll take this bug to just address that one single issue to fix things so that clicking the navigation toolbox button will not result in multiple sub toolbox instances. Anything else outside that scope can be entered in a new standalone bug if its still a problem after I try and fix that.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/4db0b6fc7f51fb5bfe2d61faf50a3063228da1c8%5E%21 Resolves: tdf#43220 ensure old popup is destroyed on replacement It will be available in 6.3.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.
backport to 6-2 in gerrit, fixed in master
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-2": https://git.libreoffice.org/core/+/ab3bfb6d8c29d41384bbaddd41bfe03fe88d9e03%5E%21 Resolves: tdf#43220 ensure old popup is destroyed on replacement It will be available in 6.2.1. 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.
Fixed. Verified on Version: 6.3.0.0.alpha0+ Build ID: 3424004cca7cb61043800f0ff0acc9de64768276 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-01-26_00:45:09 Locale: ro-RO (ro_RO.UTF-8); UI-Language: en-US Calc: threaded
Tested with version 6.2.2 (16 bit, Win 10). The behaviour respective comment 6 steps 1 to 7 does not change. So I think the fix does not work. Hence set back status to REOPENED.
I was not able to reproduce this issue on the version that I am using. Perhaps this issue has been dealt with. Version: 24.2.0.3 (X86_64) / LibreOffice Community Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 CPU threads: 24; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
(In reply to John from comment #19) Thanks John. Yes this issue was resolved. In fact the Toolbox picker was replaced, and the Navigator was refactored to use mode selection via drop listbox. I think that was done [1] for bug 89566 at the 7.0.0 release =-ref-= [1] https://gerrit.libreoffice.org/c/core/+/87005/