See also: bug 58186, bug 58189, bug 58191, bug 58192.

I can confirm this in 4.0.0 RC1. Its very annoying and makes the Navigator more or less unusable.

I get the same problem, but I find other situations where it happens.

For example:

When using the Navigator to rename a Text frame, on completion the Text frame is collapsed, the Headings and everything else are expanded, so you lose your place within the Navigator.

In other words, the Navigator is expanding and collapsing items without being asked to do so.

Operating system: Linux Ubuntu 12.04 64-bit (fully updated)
Libre Office: 4.0.0.3 (deb installation files downloaded directly from the Libre Office website)

Hence confirmed by Leif and Paddy, set to NEW.

I confirm the issue. 
Other case of occurrence : when editing a heading directly in the main document, the whole headings structure collapse in the Navigator on refresh, making the Navigator practically useless.

This bug occurs in Elementary OS (based on Ubuntu 12.04) on a 64bit system with LibreOffice 4.0.1.2

I followed instructions attached in "Example document" on LibreOffice 4.0.2.2 on Windows XP. Every click I do on "Promote Chapter" or "Demote Chapter" the Headings list gets collapsed. Pretty annoying.

Created attachment 78822 [details]
Example file

Due to a comment on the German user mailing list, I checked the behaviour again with versions 3.6.6 and 4.0.2. The behaviour is slightly different. Both versions are still not OK. I added a new example file in order to show the difference. Just open the file and perform the steps inside the document.

Hi,
I confirm this boring bug and I just found how to workaround and why it seemed not to be always reproducible:
 - in the Navigator click on  the icon "content view" 
After that there is no more collapse, on any document, with "content view" selected or not.
Verified under Vista-32b with:
- Version 4.0.5.2 (Build ID: 5464147a081647a250913f19c0715bca595af2f)
- Version: 4.1.1.2 Build ID: 7e4286b58adc75a14f6d83f53a03b6c11fa2903
- Version: 4.2.0.0.alpha0+ Build ID: 9b1e83c4f5922029ca7cd61b73bd0f8695aadedb
TinderBox: Win-x86@6-debug, Branch:master, Time: 2013-08-28_09:32:22

A simple way to reproduce the problem again is to use a new profile

I added the keyword regression because this workaround is not necessary with previous versions (verified on versions 3.3.4 and 3.5.7 under Vista-32b using a new profile)
Regards

@Michel Rudelle — Unfortunately, that workaround does not work for me. I often switch Contect View between on and off, and I always get the problem.

I confirm that this bug is still happening in version 4.1.1.2.

>  - in the Navigator click on  the icon "content view" 

Works on Version: 4.1.1.2
Build ID: 7e4286b58adc75a14f6d83f53a03b6c11fa2903

W7 Prof 64-Bit

@NWinkler: I have the same version and build as you, yet the workaround does not work for me.

However, I'm not using Windows; I'm using Linux Ubuntu 12.04 64-bit. Perhaps there is a difference between the two builds?

The attached document describes two problems: The first is a regression in LO4.0.2 against LO3.6.6, the second problem occured already in LO3.6.6.

The first (regression) comes in because the methods Expand and Collapse of SvTreeListBox were once virtual and are non-virtual in LO4.0.2, so that the specialised Expand and Collapse-methods in SwContentTree are never called.

LO 4.2.4.2 still has the problem.

Ulrich Kitzinger committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6eaad9e41ae95a3d973e72439ef580349e3e8e4b

Resolves: fdo#58187 Expand and Collapse should be virtual



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

*** Bug 83002 has been marked as a duplicate of this bug. ***

Can this one be closed? It seems resolved.

The fix has (In reply to Björn Michaelsen from comment #17)
> Can this one be closed? It seems resolved.

The fix has not been backported to branch 4.3, is it possible to do that before closing this bug as fixed ?

Best regards. JBF

I confirm that this has been fixed in 4.3.2.2 (released just a couple of weeks ago), at least in the Linux operating system Ubuntu 14.04. (Thank you to the developers.) I have not tested it in any other operating system.

(In reply to Paddy Landau from comment #19)
> I confirm that this has been fixed in 4.3.2.2 (released just a couple of
> weeks ago), at least in the Linux operating system Ubuntu 14.04. (Thank you
> to the developers.) I have not tested it in any other operating system.

That's strange, I looked at the code modified by the commit in the master and the same code in 4.3 branch has not been modified.

best regards. JBF

@Jean-Baptiste, strange indeed.

I wonder if other people following this bug would please check their versions and let us know whether or not it is working. Perhaps I have a freak version! Later today, I'll check on Windows 7 and on another Ubuntu 14.04 to see what happens.

Well, this gets interesting.

* It all works on my machine (Ubuntu 14.04).

* On another, almost identical, Ubuntu 14.04, it collapses when I rename an image but works when moving around headings.

* On Windows 7, I get the same result: it collapses when I rename an image but works when moving around headings.

I am using LibreOffice 4.3.2.2 build ID edfb5295ba211bd31ad47d0bad0118690f76407d.

Therefore, I believe that this bug should remain open until the latest available version contains the fix.

(In reply to Paddy Landau from comment #21)
> @Jean-Baptiste, strange indeed.
> 
> I wonder if other people following this bug would please check their
> versions and let us know whether or not it is working. Perhaps I have a
> freak version! Later today, I'll check on Windows 7 and on another Ubuntu
> 14.04 to see what happens.

Still present in

Version: 4.2.6.3
Build-ID: 3fd416d4c6db7d3204c17ce57a1d70f6e531ee21
(German language menus)
on the Mac

on 2014-11-09

It all appears (so far) to be working correctly on the development version, 4.4.0.0.alpha1. Version 4.4 is due for full release by 1st February, so we can check it then.

Created attachment 112141 [details]
New example file with several moves.

Checked again with version 4.4.0.2 (RC2). It seemed that the function has changed but it is still not correct. I added a new example file with several moves. Just follow the instructions inside this document.

Harald, thanks for your example file.

I tested it with the latest 4.4 (downloaded today), and my results are even worse than yours!

I think the point is that it has not been solved yet.

I'm having this on 4.3.6.1. The unasked-for collapse happens also on copy-paste operation involving move from one numbered paragraph to another (copy from one, paste to another). Formally trivial in severity, but extremely annoying.

Switch to 4.4 is completely untenable for me, because of https://bugs.documentfoundation.org/show_bug.cgi?id=88314.

Cut or copy operation by itself also triggers this, immediately. BTW, edits in headings are reflected in navigator with significant delay.

This might be a tricky one to bibisect, but it could definitely help to track down the issues, especially as comment #26 indicates that it still may not be fixed:
Whiteboard -> bibisectRequest

This bug does not appear for me.

Ubuntu 15.04 x64
Version: 4.4.2.2

@Harald: Please reset your profile and test again with 4.4.2.2 or newer.

Setting to FIXED (we know the commit)

@Harald: Please do not reopen the bug until you test with a fresh profile and the latest version of LibreOffice. If you are still able to confirm the issue please set the bug back to NEW (do not set to REOPENED)

Also in the future please include all reproducible steps in the bug report itself (not in an attached document) - this way we can easily see how it is reproduced without having to download files. Thanks!

Apologies: to reset profile visit this wiki page: https://wiki.documentfoundation.org/UserProfile

Created attachment 116279 [details]
New example file without instructions

The Bug still exists with version 4.4.3 also with a new user profile. Hence set back to NEW.

In order to reproduce the bug:

(1) Open this example file.
(2) Display Navigator, display only headings in Navigator, expand all headings.
(3) Move Heading1112 --> between Heading11 and Heading111: Headings still expanded, OK.
(4) Move back Heading1112 --> between Heading1111 and Heading1113: Headings still expanded, OK.
(5) Move again Heading1112 --> between Heading11 and Heading111: Heading111 collapses inside Navigator. Expected: No collaps. Expand Heading111 again.
(6) Move Heading1112 --> between Heading1 and Heading11: Heading11 collapses. Expected: No collaps. Expand Heading11 again.
(7) Move Heading1112 --> before Heading1: Heading1 collapses. Expected: No collaps. Expand Heading1 again.
(8) Move Heading2112 --> between Heading21 and Heading211: Heading 211 collapses. Expand it again.
(9) Move Heading2112 --> between Heading11 and Heading111: Heading111 and Heading21 collapse. Expand them again.
(10) Move Heading2112 --> between Heading2 and Heading21: Heading111 collapses. Expand it again.
(11) Move Heading2112 --> between Heading1 and Heading11: Heading2 and Heading111 collapse. Expand them again.
(12) Move Heading2112 --> before Heading1: Heading1 collapses.

(In reply to Harald Koester from comment #33)
> Created attachment 116279 [details]
> New example file without instructions
> 
> The Bug still exists with version 4.4.3 also with a new user profile. Hence
> set back to NEW.
> 
> In order to reproduce the bug:
> 
> (1) Open this example file.
> (2) Display Navigator, display only headings in Navigator, expand all
> headings.
> (3) Move Heading1112 --> between Heading11 and Heading111: Headings still
> expanded, OK.

So for me at this point one of them collapses - so it's not OK. That being said I checked 3.3 and I see the same issue.

Can someone please check 3.3 and verify that this is in fact a regression - else we need to remove regression and bibisectRequest from whiteboard/keyword.

http://downloadarchive.documentfoundation.org/libreoffice/old/

The sooner the better just so that we can get this accurately triaged.

I'm also changing priority to conform with our objective criteria:

Minor - can slow down professional quality work but will not prevent it;
Low - default for minor bugs

Please don't adjust those - they are objective standards/criteria. Thanks all for your patience.

> So for me at this point one of them collapses - so it's not OK. That being
> said I checked 3.3 and I see the same issue.
> 
> Can someone please check 3.3 and verify that this is in fact a regression -
> else we need to remove regression and bibisectRequest from
> whiteboard/keyword.

Checked with version 3.3.0 and 5.0.0.5. Bug exists in both versions. There is one difference in the test procedure according comment 33. Due to the existence of bug 58189 in version 3.3.0 the behaviour is different at step (6). In order to perform the procedure of comment 33 with both versions (3.3.0, 5.0.0.5) perform this at step (6):

(6) Move Heading1112 --> between Heading1 and Heading11: 
(a) Version 5.0.0: Heading11 collapses. Expected: No collaps. Expand Heading11 again.
(b) Version 3.3.0: Heading1112 is moved below Heading1113. Wrong move! In order to get the same preconditions for step (7): Move Heading1112 before Heading1 (Heading111 collapses), then move Heading1112 between Heading1 and Heading11. Expand Heading111. 

Keywords "regression" and "bibisectRequest" removed, because bug exists already in version 3.3.0. Furthermore version set to "Inherited from OOo". Hoping that's all OK.

Bug according comment 33 still exists in version 5.2.2 with Win7.

This bug was never confirmed by a third person.
Could you please try to reproduce it with the latest version of LibreOffice
from https://www.libreoffice.org/download/libreoffice-fresh/ ?
I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' if the bug is still present in the latest version.

As far as I can tell, everything is working correctly now.

Closing as RESOLVED WORKSFORME then...

Checked again with version 5.4.1 and Win 7. Bug according test procedure of comment 33 still exists. 

This bug has been confirmed by several persons: See comments 2, 3, 5, 6, 9, 23. Hence I think it's OK if I set the status to NEW by my own, even if no one of these persons has set the status to NEW.

Works for me.

Version: 6.0.6.2
Build ID: 1:6.0.6-0ubuntu0.16.04.1
Linux Ubuntu 16.04.5 64-bit

Checked again with version 6.1.0 (64 bit, Win 10). 
Bug according test procedure of comment 33 still exists.

Checked again with version 6.3.2 (64 bit, Win 10). 
Bug according test procedure of comment 33 still exists.

I believe this merged patch fixes this:
https://gerrit.libreoffice.org/c/core/+/125083