Bug 118550 - EDITING: Manage Styles Dialogue (F11) became unusable.
Summary: EDITING: Manage Styles Dialogue (F11) became unusable.
Status: RESOLVED DUPLICATE of bug 101915
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.0.4.2 release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: User-Profile
  Show dependency treegraph
 
Reported: 2018-07-05 12:35 UTC by Albrecht Müller
Modified: 2018-07-13 12:19 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
docking the Sidbar deck (19.01 KB, image/png)
2018-07-09 12:09 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Albrecht Müller 2018-07-05 12:35:51 UTC
Description:
The effect of trying to open the manage styles dialogue is that this dialogue is visible for a split second and then disappears. It does not matter if I try to open the dialogue using the menu (Styles -> Manage Styles) or if I use the shortcut F11. Staying on F11 until the key repeat mechanism becomes active shows a constantly flashing dialogue. So the complete functionality of this dialogue becomes unusable.

Restarting LibreOffice and a reboot of the operating system did not change this behaviour. The dialogue works when I start Writer in save mode. It appears in the sliding window on the right.

Enabling or disabling OpenGL as described in https://wiki.documentfoundation.org/OpenGL#How_to_enable.2Fdisable_OpenGL did not change the effect.

Steps to Reproduce:
I do not know how I achieved this behaviour. Maybe its caused by importing styles from some other document, playing around with automation macros in Basic or by some of the recent crashes.

Actual Results:
I am still trying to find a way to make the dialogue usable again and analysing how I can minimise the damage caused by the use of options in save mode. As libreoffice-profile.zip contains more than 300 MB I fear considerable loss of data, e.g. macros, autocorrection entries, collected words in spelling dictionaries etc. 

Expected Results:
I can work on my documents without worrying about user profiles. LibreOffice should be resilient in the sense that it should not be possible to inadvertently disable parts of its functionality.


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Version: 6.0.4.2 (x64)
Build-ID: 9b0d9b32d5dcda91d2f1a96dc04c645c450872bf
CPU-Threads: 4; BS: Windows 6.1; UI-Render: Standard; 
Gebietsschema: de-DE (de_DE); Calc: group
Comment 1 V Stuart Foote 2018-07-05 13:23:33 UTC
Well the obvious thing is to test in SAFE mode (Help -> Restart in Safe Mode ).

It will allow you to run "Continue in Safe Mode" (changing nothing) with a default profile, just assuring you your installation and hardware are not the issue.

The dialog will give you options to configure user extensions and hardware acceleration, or to reset extensions.

Unfortunately, beyond that teasing out what in a 300MB profile is causing issues with the Style sidebar deck is going to be a tedious trial and error process of adjustment.

For now, let us know how Safe Mode or a clean profile (keep the backup .zip safe) works.
Comment 2 Albrecht Müller 2018-07-05 17:53:02 UTC
The dialogue works when I start Writer in save mode. It appears in the sliding window on the right. I reset the profile - this also works. This means I actually lost all my configuration information.

Unfortunately the user interface is not very clear about how to restore the user profile from a backup. There are two checkboxes:

"Restore user configuration to the last known working state"
and
"Restore state for installed user extension to the last known working state".

Where does LibreOffice get this "last known working state" from? How can I tell LibreOffice to restore exactly the state I saved into libreoffice-profile.zip?

For now I cannot restore the profile from the backup in the .zip-file. So I cannot reproduce the problem any more.

After the creation of the .zip I compared its content with the user directory. There were a lot of differences. Therefore I did not try to simply unpack the .zip file into the user directory.
Comment 3 V Stuart Foote 2018-07-05 19:17:07 UTC
(In reply to Albrecht Müller from comment #2)
> The dialogue works when I start Writer in save mode. It appears in the
> sliding window on the right. I reset the profile - this also works. This
> means I actually lost all my configuration information.

OK, then we know it is not a hardware issue. Also, you did not loose your "old" configuration details because you have the original Zip of the profile--of course it is still broken.

> 
> Unfortunately the user interface is not very clear about how to restore the
> user profile from a backup. There are two checkboxes:
> 
> "Restore user configuration to the last known working state"
> and
> "Restore state for installed user extension to the last known working state".
> 
> Where does LibreOffice get this "last known working state" from? How can I
> tell LibreOffice to restore exactly the state I saved into
> libreoffice-profile.zip?

Good question, I've not poked at it that much. Prefer to just rebuild my profile and customizations, YMMV.

> 
> For now I cannot restore the profile from the backup in the .zip-file. So I
> cannot reproduce the problem any more.
> 
> After the creation of the .zip I compared its content with the user
> directory. There were a lot of differences. Therefore I did not try to
> simply unpack the .zip file into the user directory.

Deleting the "clean" profile, and simply unpacking the .zip of the "old" broken profile is the means to restore the old profile--each attempt--at resolving the issue with the Styles (F11) content panel in the Sidebar.  

There is a lot of junk that builds up over time in the user profile--so your choice about trying to tease out what is causing the problem, or of rebuilding the profile and customizations.

Given that it is happening on the F11 Styles panel, suggests there is a broken Paragraph style defined. Although I guess it could be any of Paragraph, Character, Frame, Page, List or new Table style defined that is no longer valid.
Comment 4 Albrecht Müller 2018-07-06 19:19:54 UTC
(In reply to V Stuart Foote from comment #3)

> > Where does LibreOffice get this "last known working state" from? How can I
> > tell LibreOffice to restore exactly the state I saved into
> > libreoffice-profile.zip?
> 
> Good question, I've not poked at it that much. Prefer to just rebuild my
> profile and customizations, YMMV.
 
I hoped that I could simply restore the previous state of the profile. Unfortunately I did not find an operation that allows me to restore the profile from the .zip. Just unpacking the .zip will not restore registry entries. I do not expect that LibreOffice will handle resulting inconsistencies gracefully.

Therefore I think I have to accept that I lost my profile information and have to follow your way. Hopefully I will be able to restore some of the lost data from the .zip.

> > For now I cannot restore the profile from the backup in the .zip-file. So I
> > cannot reproduce the problem any more.
> > 
> > After the creation of the .zip I compared its content with the user
> > directory. There were a lot of differences. Therefore I did not try to
> > simply unpack the .zip file into the user directory.
> 
> Deleting the "clean" profile, and simply unpacking the .zip of the "old"
> broken profile is the means to restore the old profile--each attempt--at
> resolving the issue with the Styles (F11) content panel in the Sidebar.  
 
That's exactly what I try to avoid as I fear this action may worsen the damage. After the generation of the .zip I compared it to the original profile directory and I think I found substantial differences. This was no surprise. The complete information that allows to restore the state of LibreOffice may contain registry information. The user may have redefined path information, and there may be other information on places I do not know about.

> There is a lot of junk that builds up over time in the user profile--so your
> choice about trying to tease out what is causing the problem, or of
> rebuilding the profile and customizations.

Of course: The backup directory seems to contain many versions of the same file. At least one of them has more than 100 versions. I was not aware LibreOffice keeps this kind of backups - I thought it would keep just one backup file. Unfortunately all versions got the same timestamp so I cannot easily find out when these backups were generated. I also found a number of .pack-files. These seem to contain some compressed content. As I do not have any tool that's able to unpack them I cannot assess if they contain relevant content.

> Given that it is happening on the F11 Styles panel, suggests there is a
> broken Paragraph style defined. Although I guess it could be any of
> Paragraph, Character, Frame, Page, List or new Table style defined that is
> no longer valid.

Sounds plausible. I imported styles from some other, older document. I think the preview checkbox was activated. So the dialogue may open, tries to render the styles, gets an uncaught exception due to some bad style and disappears. Assuming this hypothesis is correct an easy fix would have been to find out the location where LibreOffice stores the state of the checkbox and to turn it off. So the dialogue would not use a bad style for rendering => no exception => dialogue remains on screen.

I have a fundamental problem here. LibreOffice tries to handle user profiles as single monolithic entities in a way that might be appropriate if a user profile affects only a few preference settings that you can easily rebuild by hand. In fact user profiles are pretty complex things and you can invest any amount of time into creating one: Write macros, design consistent document styles, create autocorrect entries for hard to find UTF-8 codes, write autotext entries and more. If you are in "Safe Mode" you may destroy all this work with a few clicks of the mouse.
Comment 5 V Stuart Foote 2018-07-06 19:42:43 UTC
(In reply to Albrecht Müller from comment #4)
> I hoped that I could simply restore the previous state of the profile.
> Unfortunately I did not find an operation that allows me to restore the
> profile from the .zip. Just unpacking the .zip will not restore registry
> entries. I do not expect that LibreOffice will handle resulting
> inconsistencies gracefully.
> 

There is just one LibreOffice "registry" involved with the user Profile

registrymodifications.xcu

While some settings can be written to Windows OS registry per user--but that depends on installation type--for the most part system registry is untouched in configuring LibreOffice.

The stanza for styles in the LibreOffice registry is:

<item oor:path="/org.openoffice.Office.Common/StylesAndFormatting"><prop oor:name="Preview" oor:op="fuse"><value>false</value></prop></item>

since defaults are to preview styles, this stanza is not created by default, and must be added to the registrymodifications.xcu configuration. It then can be toggled true/false from the GUI or a text editor.
Comment 6 Albrecht Müller 2018-07-07 20:03:46 UTC
Thanks for your information. Based on it I dared to experiment with the user profile directory. That's the current state of affairs:

I found out that Windows happened to save a backup of the "user" directory just a day before the problem appeared. This way I could restore an almost current working state (great Windows feature!). I put the directory containing the "user" directory under git version control and saved this version. I then replaced the contents of the "user" directory with the contents of the libreoffice-profile.zip file I generated using LibreOffice's Safe Mode and committed this version too.

The comparison of the two commits showed that the backup created by LibreOffice has some defects:
- It seems to contain no or wrong timestamps.
- The names of some files in the "wordbook" subdirectory  were different. LibreOffice seems to replace spaces, umlauts and some other characters by the percent encoded representation of their UTF-8 codes. I observed this effect in some other directories too. This led to some problems with spell checking. I did not look for problems this may cause in other areas.

With respect to the "Manage Styles" dialogue the two profiles behave as expected. It is functional when I use the profile restored from the Windows backup, and it does not work when I use the version from the .zip. This way I can reproduce the problem. When I copied the registrymodifications.xcu from the version that does not work into the one that does the "Manage Styles" dialogue ceases to work. So I think the problem is related to the contents of this file.

I could test the "bad style hypothesis" - it seems to be wrong. In a not working profile I changed the stanza you mentioned to toggle the preview styles checkbox. Unfortunately the "Manage Styles" dialogue disappears as before. In the flickering dialogue box (repeating F11 key) I could see that the checkbox did not use style preview, i.e. the checkbox is off.
Comment 7 Albrecht Müller 2018-07-07 21:02:39 UTC
Additional observations:

The working version of registrymodifications.xcu contains a line 

<item oor:path="/org.openoffice.Office.UI.Sidebar/Content"><prop oor:name="LastActiveDeck" oor:op="fuse"><value><it>any,PropertyDeck</it><it>com.sun.star.chart2.ChartDocument,ChartDeck</it><it>com.sun.star.sdb.FormDesign,PropertyDeck</it><it>com.sun.star.sheet.SpreadsheetDocument,NavigatorDeck</it></value></prop></item>

The correspondig line in the version that does not work is:
<item oor:path="/org.openoffice.Office.UI.Sidebar/Content"><prop oor:name="LastActiveDeck" oor:op="fuse"><value><it>any,PropertyDeck</it><it>com.sun.star.chart2.ChartDocument,ChartDeck</it><it>com.sun.star.sdb.FormDesign,PropertyDeck</it><it>com.sun.star.sheet.SpreadsheetDocument,NavigatorDeck</it><it>com.sun.star.text.TextDocument,StyleListDeck</it></value></prop></item>

By changing this line I could achieve that the "Manage Styles" dialogue becomes functional, i.e. it stays on the screen. Unfortunately this works only once. LibreOffice seems to recreate the defect entry when it is closed. Therefore the dialogue is not functional when I start LibreOffice next time. The same thing happens when I close the "Manage Styles" dialogue and try to show it again. It disappears immediately as before.

I could fix this behaviour by dragging the "Manage Styles" dialogue into a docked area - it stayed there after restart of LibreOffice. After dragging it back to some other area it showed the same behaviour as before, i.e. disappeared.
Comment 8 Xisco Faulí 2018-07-09 11:15:44 UTC
> I could fix this behaviour by dragging the "Manage Styles" dialogue into a
> docked area - it stayed there after restart of LibreOffice. After dragging
> it back to some other area it showed the same behaviour as before, i.e.
> disappeared.

So the problem is only reproducible with no docked dialogue?
OTOH, could you reproduce the problem from scratch with a clean profile ?
Comment 9 V Stuart Foote 2018-07-09 12:09:35 UTC
Created attachment 143394 [details]
docking the Sidbar deck

Just realized you are launching with the Sidebar deck in the Undocked state.

Do things improve if on your first launch after recovery you "Dock" the Sidebar from its button bar?
Comment 10 Albrecht Müller 2018-07-11 15:49:49 UTC
> Do things improve if on your first launch after recovery you "Dock" the
> Sidebar from its button bar?
No - Observation:
- Open a Writer-Document
- Press F11 -> sidebar opens and shows Manage Styles Dialogue
- Press F11 -> sidebar slides back
- Press F11 -> sidebar opens again
- Drag sidebar to some non-docking position -> dialogue stays there
- Press F11 -> dialogue disappears
- Press F11 -> dialogue appears for a split second and disappears, i.e. dialogue is unusable. It is therefore not possible to use the dock menu entry.
- Close Writer and open again -> Works as expected
- Press F11 -> dialogue appears for a split second and disappears, i.e. problem persists
- Close Writer
- Restore registrymodifications.xcu from git
- Open Writer
- Press F11 -> sidebar shows Manage Styles Dialogue
- Press F11 -> sidebar slides back
- Press F11 -> sidebar opens again
- etc.  i.e. Manage Styles Dialogue is functional again.

> OTOH, could you reproduce the problem from scratch with a clean profile ?
I don't know: I saw this behaviour also in safe mode: Dragged the dialogue from the sidebar to some non-docking position,  closed it pressing F11. Next press F11 showed the problem: The dialogue reappears only for a split second. But my theory that save mode uses a clean profile seems to be wrong as I tried to reproduce the problem and found that the Manage Styles Dialogue was not functional right from the next start of Writer in safe mode.

I did some other experiments with the sidebar. Instead of pressing F11 I tried the open the Manage Styles Dialogue from the main menu. This had the same effect as hitting F11. The same menu has an entry to toggle the sidebar and one to show the gallery. Both entries work. This way it is possible to access the Manage Styles Dialogue in the non-docked state. And you can bring it in the docked state where it works normally.

There are other strange phenomena I observe. I think they are related:

I think the F5 key should show the same behaviour as the F11 key but it does not. Both keys should open a dialogue that you can dock in the sidebar at the right. The differences are (assuming the dialogues are docked at right):

Pressing F11:  Toggles the sidebar between visible and invisible state.
Pressing F5:  Seems to do the same. I you look closer you will see differences:
F11 creates a sidebar if there is none. Another F11 just minimizes the sidebar. It stays there until you close it using its menu in the upper right corner. F5 seems to create a dialogue and to remove it when you press F5 again. Using the marker on the left side of the dialogue you can make it slide to the right. If you press F5 in this state then the only effect is that the marker disappears.

Pressing F5 and F11 you can have two dialogues in the sidebar, one controlled by the F5 and one by the F11 key. The latter has a menu button in its upper right corner. The former has no such button. The button allows you to switch from the Manage Styles Dialogue to a Navigator dialogue. This way you can have two almost identical looking navigator dialogues in the sidebar. Pressing F11 switches one of these windows back to the Manage Styles Dialogue, pressing F5 makes the other navigator disappear. Pretty confusing. I miss a clear user interface concept: Why can I see navigator and styles at the same time but not styles and gallery? Why is the number of navigator dialogues limited to two?
Comment 11 V Stuart Foote 2018-07-11 17:02:42 UTC
(In reply to Albrecht Müller from comment #10)
> ...
> There are other strange phenomena I observe. I think they are related:
> 
> I think the F5 key should show the same behaviour as the F11 key but it does
> not. Both keys should open a dialogue that you can dock in the sidebar at
> the right. The differences are (assuming the dialogues are docked at right):
> 
> Pressing F11:  Toggles the sidebar between visible and invisible state.
> Pressing F5:  Seems to do the same. I you look closer you will see
> differences:
> F11 creates a sidebar if there is none. Another F11 just minimizes the
> sidebar. It stays there until you close it using its menu in the upper right
> corner. F5 seems to create a dialogue and to remove it when you press F5
> again. Using the marker on the left side of the dialogue you can make it
> slide to the right. If you press F5 in this state then the only effect is
> that the marker disappears.
> 
> Pressing F5 and F11 you can have two dialogues in the sidebar, one
> controlled by the F5 and one by the F11 key. The latter has a menu button in
> its upper right corner. The former has no such button. The button allows you
> to switch from the Manage Styles Dialogue to a Navigator dialogue. This way
> you can have two almost identical looking navigator dialogues in the
> sidebar. Pressing F11 switches one of these windows back to the Manage
> Styles Dialogue, pressing F5 makes the other navigator disappear. Pretty
> confusing. I miss a clear user interface concept: Why can I see navigator
> and styles at the same time but not styles and gallery? Why is the number of
> navigator dialogues limited to two?

Ancient history. As implemented for bug 73151 a separate instance of the Sidebar framework to allow an F5 Navigator "content panel" to be open with any _single_ "content panel" on the Sidebar's deck.  

At some point the Sidebar framework will be refactored to support multiple detached content panels returning us to the era of each dialog having its own implementation in source. That is work needed for bug 85905

Until then, the F5, F11, <ctrl>+F5 are shortcuts assigned to control the Sidebar framework--supplementing the View and the Styles main menu entries, and have had subtle UI changes at 5.4, 6.0, 6.1 and current master/6.2

Shortcuts behave a bit odd if the cursor focus is not on the document canvas--pay attention to where the UI is active.

And seems most of your issues with your profile are with trying to work with the Sidebar Deck in an undocked state. IHMO the Styles content panel of the Sidebar Deck and what you incorrectly call "Manage Styles" (its label on the Styles menu) is not intended to be undocked by default as you've left it in profile. Dock it and see if you can recover your profile to a reliable state.
Comment 12 Albrecht Müller 2018-07-12 15:39:37 UTC
It took me a long way to come there but this bug is not a problem for me any more as I now can reproduce and repair it with a few key strokes or clicks of the mouse (see my answers in comment #10). 

I do not know if this problem is related to the contents of my profile or if this is a trap for other users who do not know the trick.

Note: I observed the sidebar disappear only when I tried to make it visible in undocked state to show styles. When I tried to show the gallery the dialogue remains on screen as expected. I was not aware of all these UI discussions.
Comment 13 Xisco Faulí 2018-07-13 10:15:57 UTC
(In reply to Albrecht Müller from comment #12)
> It took me a long way to come there but this bug is not a problem for me any
> more as I now can reproduce and repair it with a few key strokes or clicks
> of the mouse (see my answers in comment #10). 

Should it be closed as RESOLVED WORKSFORME then ?
Comment 14 V Stuart Foote 2018-07-13 12:19:09 UTC
will go ahead duplicate this to bug 101915 where behavior with mix of <F11> and <ctrl>+<F6> has been refined at 6.1.0 and master/6.2

@Jim R. any further thoughts?

*** This bug has been marked as a duplicate of bug 101915 ***