Bug 73996 - VIEWING: If page pane is disabled, toolbars are not displayed when opening new drawing
Summary: VIEWING: If page pane is disabled, toolbars are not displayed when opening ne...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard: target:6.2.0 target:6.1.4
Keywords:
Depends on:
Blocks: Slide-Page-Pane
  Show dependency treegraph
 
Reported: 2014-01-23 22:52 UTC by tmacalp
Modified: 2023-06-29 14:11 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tmacalp 2014-01-23 22:52:17 UTC
Description:
Since LO 4.0.x, it has been possible to close Draw's page pane and have that setting remembered.  If you open a brand new drawing while your page pane is disabled, all toolbars are missing.  If you click in the document, the toolbars come back and everything is peachy.  If you try to enable the page pane again while the toolbars are missing, LO CRASHES.

Steps to reproduce:
1. Open a new Draw drawing
2. If pane page is enabled, disable it (View -> Page Pane)
3. Close the drawing
4. Open a new drawing

Expected:
All toolbars should show and everything should look/work like normal.

Actual:
Only the main toolbar shows.  At this point you can do one of two things:

1. If you click in middle of drawing, the screen redraws and the toolbars come back.
2. If you re-enable the page pane (View -> Page Pane) while the toolbars are still missing, LO will CRASH and you will lose any unsaved work.

I can confirm this bug affects a number of versions:
LO 4.1.4.2 under 32bit Windows 7
L0 4.1.4.2 under 32bit ArchBang
L0 4.0.2.2 under 32bit Fedora17
L0 4.1.4.2 under 32bit Fedora17
LO 4.2.0.2 rc under 32bit Fedora17

I also tested LO 3.5.7.2 under Fedora 17, but in this version, it wasn't possible to permanently disable the page pane.  Because of this, I'm setting the version to 4.0.0.3.
Comment 1 tmacalp 2014-02-26 23:04:13 UTC
I can confirm that this still affects LO 4.2.1.1 under 32bit Fedora 17.  This bug seems very very reproducible, so I'll go ahead and change status to New.

I will also attempt to properly prioritize it according to the bug prioritization flowchart.  Since this bug repeatably leads to a crash, that appears to automatically classifies it as a minimum of "medium-critical."

https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg
Comment 2 tmacalp 2014-04-11 03:28:15 UTC
I just tried to reproduce this bug on another system and realized that disabling desktop effects is vital to reproducing this bug.  In all of my previous test environments, fancy desktop effects were disabled.  These effects may cause the screen to redraw and make this bug untestible.  

For instance, to test under MS Windows, 
Control Panel -> System -> Performance Settings -> "Adjust for best performance"

Under my Linux environments, I've been using IceWM and OpenBox with no effects enabled.
Comment 3 tmacalp 2014-05-19 15:18:40 UTC
I think I figured out the primary cause of the bug: I have a toolbar docked to the left side of the page in my test environments.

My guess is that side-docked toolbar positioning is somehow causing a conflict with the hidden page pane.
Comment 4 crxssi 2014-12-16 17:17:07 UTC
Confirmed in RHEL 6 + LO 4.3.4.1 and some older versions too.  Had noticed this a long time ago but never reported it....my bad... especially since I do like to have the annoying page page hidden and I also have the "Drawing" toolbar on the left.

As a possibly related problem- when I have the page page hidden, when I start a NEW draw document window, the "Drawing" toolbar doesn't even show on the screen until I click into the page area.  Doesn't matter where you dock the "Drawing" toolbar.  Should I report this as a different bug?
Comment 5 tmacalp 2014-12-16 22:12:07 UTC
(In reply to crxssi from comment #4)
> As a possibly related problem- when I have the page page hidden, when I
> start a NEW draw document window, the "Drawing" toolbar doesn't even show on
> the screen until I click into the page area.  Doesn't matter where you dock
> the "Drawing" toolbar.  Should I report this as a different bug?

You're right about the toolbar location not having anything to do with this bug.  I was able to reproduce this bug without the toolbar on the left.  Other than that, your description seems to match my original post, so I believe you are suffering from the same bug.

Unfortunately, this bug is very intermittent for me.  I'll go back to actively trying to figure out how to reproduce it.
Comment 6 tmacalp 2014-12-17 02:27:21 UTC
OK, I think one of the factors is the theme.

I started with a base system of archbang (openbox on arch linux) with LibreOffice 4.3.4.1 installed.  Here are my steps/conclusions in order:

1. Removed my ~/.config/libreoffice/4 directory to start fresh
2. Start LO
3. New Drawing

At this point everything came up correctly since I had a page pane and I haven't changed themes.

4. Disabled page pane (View->Page Pane)
5. Close drawing (Ctrl-w)
6. New Drawing

At this point, everything came up correctly since we haven't changed themes.

7. Change theme to galaxy (Tools->Options->View->Icon Style to Galaxy
8. OK
9. Close drawing (ctrl-w)
10. New Drawing

BUG! Only the "Standard Toolbar" at the top is visible.  If you click anywhere, the other toolbars will redraw or if you perform a view->page pane, LO will crash.

At this point, if I change the theme back to the default of Tango, everything is fine and I'm not able to trigger the bug.

Themes that trigger bug:
Hicontrast
Crystal
Galaxy

Themes that do NOT trigger bug:
Sifr
Oxygen
Tango

I also tested this under LO 4.2.7.2 using Mint 17 using Xfce.  The only theme installed was "Human" and that triggered the bug too.
Comment 7 tmacalp 2015-09-11 21:02:39 UTC
This one isn't testable as of version 5.0 because of bug 90987, which is a regression that doesn't allow draw/impress to remember the previous states (open/close, hidden/shown) of the sidebar or page pane.
Comment 8 Armin Le Grand (allotropia) 2015-11-10 11:07:47 UTC
Checked on Win7 LO 5.1.0.0.alpha1+
Opening draw 2nd time indeed hides the left toolbar (the one with the shapes). Klicking to the doc brings it back. Reactivating the page pahe does not crash here, tried several times.
Comment 9 tmacalp 2015-11-12 20:13:33 UTC
(In reply to Armin Le Grand from comment #8)
> Checked on Win7 LO 5.1.0.0.alpha1+
> Opening draw 2nd time indeed hides the left toolbar (the one with the
> shapes). Klicking to the doc brings it back. Reactivating the page pahe does
> not crash here, tried several times.

I can confirm your findings!  The crash part at least appears to be fixed in the master nightly.

LO 4.4.6.3 will, of course, still crash.  And as mentioned above, LO 5.0.x versions have a bug where the page pane doesn't remember its state.
Comment 10 tmacalp 2015-12-29 21:36:03 UTC
Since this bug no longer causes a crash, I've updated the title and have greatly reduced the importance fields.  I even thought about closing it as worksforme, but the original description is still mostly valid.

Also, for an update, bug 90987 was fixed in LO 5.0.4, so page pane state is back to being remembered again and this bug is once again testable on the 5.0 branch.
Comment 11 QA Administrators 2017-01-03 19:54:37 UTC Comment hidden (obsolete)
Comment 12 tmacalp 2017-03-10 16:59:36 UTC
I can still reproduce this in
Version: 5.3.0.3
Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: x11; Layout Engine: new; 
Locale: en-US (en_US.UTF-8); Calc: group
Comment 13 QA Administrators 2018-03-11 03:41:40 UTC Comment hidden (obsolete)
Comment 14 QA Administrators 2020-03-11 03:25:16 UTC Comment hidden (obsolete)
Comment 15 QA Administrators 2022-03-12 03:38:02 UTC Comment hidden (obsolete)
Comment 16 Stéphane Guillou (stragu) 2023-06-29 14:11:49 UTC
This is resolved since libreoffice-6.1.4.1

Checking with the linux-64-6.1 bibisect repo, the fixing commit is Caolán's 45519023aa44940a68f40643fdff6551a2b7adb3 for bug 119997 but not marking as a duplicate as it started at different times.

Thanks Caolán and everyone else!