Bug 117258 - VIEWING: sometimes menu bar is rendered as disabled (but works)
Summary: VIEWING: sometimes menu bar is rendered as disabled (but works)
Status: RESOLVED NOTOURBUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
6.0.3.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-04-26 16:41 UTC by Lorenzo Chiola
Modified: 2018-12-05 15:55 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Obvious manifestation of the bug (186.79 KB, image/png)
2018-05-31 16:18 UTC, Lorenzo Chiola
Details
My theme, in a compressed Arch Linux package format (26.93 KB, application/x-xz)
2018-12-04 13:18 UTC, Lorenzo Chiola
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lorenzo Chiola 2018-04-26 16:41:46 UTC
This happened to me in Writer, Draw and Impress so far.

While doing some things (e.g. saving a document), LibreOffice GUI disables all of its controls to prevent the user from giving input while the GUI isn't responsive. During this time the widgets are drawn in a typical "grayed out" palette. When it finishes, the widgets are enabled again.

Issue:
Sometimes the menu bar remains coloured in the "disabled" mode, "grayed out", even if it has come back active (I mean, I can click on the menu items and use the GUI, they are just drawn the wrong way);

Note that the items within each menu and the other widgets all over the GUI are drawn correctly (enabled or disabled as they should).

I think it happens only after saving the document, but I never noticed a particular pattern for when the issue is manifested.
The last time I came across this bug was yesterday, only once, while trying things for two other reports, so while saving files many times.

It happened with the old GTK2 GUI (I think?) and with at least two different GTK3 themes: one is the default adwaita, the other is a custom theme I edited myself.
The issue is rare and I'm not able to reproduce it regularly; it may well happen in Calc too, but I use it less frequently.

I do not have any screenshots of this, but I may post one in the future if I'm (un)lucky enough.
Comment 1 Xisco Faulí 2018-05-30 09:42:34 UTC
Thank you for reporting the bug.
Unfortunately without clear steps to reproduce it, we cannot track down the origin of the problem.
Please provide a clearer set of step-by-step instructions on how to reproduce the problem.
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the steps are provided
Comment 2 Lorenzo Chiola 2018-05-31 16:18:26 UTC
Created attachment 142454 [details]
Obvious manifestation of the bug

It happened again, so I captured it (in the remote hope it can be useful).

What I did this time:
- Open the almost empty document I created this morning (Yes, I just wrote the title until now);
- Resized the window to work besides another document;
- Edited the "Title" and "Subtitle" styles;
- Left it alone while reading paper notes and using other programs;
- Not saved yet.
- Then I noticed the menus were drawn in the wrong palette.

You can see:
- The menu otherwise works as expected (it's clickable, I mean);
- The rest of the toolbars are drawn in the correct palette, and the contents of the menu are correct too.

You cannot see:
- I have another LO window open (maximized, with a document loaded), and it still looks right. This window was opened after the bugged one, but before the bug manifested (in the other window).

Aftermath:
- While writing this report, I continued to try things on the bugged window. At once, when the window got focus again, menus were displayed back in the active palette (correct behaviour). I don't think I did anything else really.

I did not change from NEEDINFO as we still need info... right? This is far from reproducible.
Comment 3 Lorenzo Chiola 2018-05-31 18:03:53 UTC
The bug manifested again, this time I clearly saw it happen.
While AutoRecovery information of the document was being saved, the menu bar has been disabled, then reenabled, but is still drawn in the wrong palette (the same as when it's disabled).

Note:
- AutoRecovery is not autosave, which I disabled after installation;
- The window is the same of the previous comment (the one with the screenshot): I haven't closed it yet.
Comment 4 Lorenzo Chiola 2018-06-01 09:29:03 UTC
Today I'm able to reproduce this every time.
- In Writer, Impress and Math, version 6.0.4.2 (official x64 Arch Linux package)
- Custom GTK3 theme, which causes two warnings in stdout of LO when starting, and no more during usage (including when the bug appears)
- With any document
- "Maximized", "vertically maximized" and "normal" window modes

- resizing the window, or changing the layout (e.g. to edit a Formula, as I did) restores the menu to the active palette (correct).

- I wasn't able to reproduce using default "Adwaita" theme, so I'm going to further investigate my theme issues first.

- I wasn't able to reproduce in Calc, Draw and Base, which do not disable the menu bar while saving.
- In my few experiments with Adwaita, the menu bar was not disabled while saving.

- While loading documents (from the recent drop down in the toolbars), the menu bar disappeared some times (maybe this deserves its own bug?). This happened with both themes, but few times. It may be just related to the time needed to change the interface, and isn't annoying anyway, but it felt worth reporting here.
- Sometimes the mouse pointer switches from arrow to grabbing-hand when hovering the menu, and doesn't change back until menu usage has been done (e.g. after clicking file->save, it will change back to arrow). Again, this is not annoying and probably would deserve another thread.
Comment 5 Xisco Faulí 2018-06-04 09:22:21 UTC
Could you please paste the info from Help - about LibreOffice ?
Comment 6 Lorenzo Chiola 2018-06-04 11:44:46 UTC
"About LibreOffice" says:

Version: 6.0.4.2
Build ID: 6.0.4-1
CPU threads: 4; OS: Linux 4.16; UI render: default; VCL: gtk3; 
Locale: it-IT (it_IT.UTF-8); Calc: group

And below: "This release was supplied by Arch Linux."

I haven't reviewed my custom theme yet. Since i've found some dialogs that are shown obviously wrong (widgets without borders, for example), it may be the culprit.
Comment 7 Xisco Faulí 2018-06-05 09:35:04 UTC
> I haven't reviewed my custom theme yet. Since i've found some dialogs that
> are shown obviously wrong (widgets without borders, for example), it may be
> the culprit.

Could you please try with another theme to be sure?
Comment 8 Lorenzo Chiola 2018-06-05 13:06:14 UTC
Adwaita works (comment 4); I also tested Numix and OneStepBack and they all behave. Menus are not disabled while saving.
I set the theme both with GTK_THEME=Adwaita and within ~/.config/gtk-3.0/settings.ini
Comment 9 Xisco Faulí 2018-06-06 10:42:59 UTC
So, what the same of the theme failing ?
Comment 10 QA Administrators 2018-12-03 13:13:32 UTC Comment hidden (obsolete)
Comment 11 Lorenzo Chiola 2018-12-04 13:18:19 UTC
Created attachment 147274 [details]
My theme, in a compressed Arch Linux package format

This theme is the one causing the issue within LibreOffice. I had no time to debug it, and it's worthless waiting longer. It is a version of https://github.com/vlastavesely/raleigh-reloaded/, modified by me without knowing much about GTK themes' formats.
Obviously I'm not asking for somebody to debug it. I'm uploading this theme because maybe it can be useful to the LibreOffice project to test the UI against a faulty theme.

I think it can be said, this bug isn't fault of Libreoffice.
Comment 12 Xisco Faulí 2018-12-05 10:20:48 UTC
Hi Lorenzo Chiola,
so I assume the problem is only happening when using your own theme, right? have you reproduce it with any other theme?
I guess we can close this as RESOLVED NOTOURBUG
Comment 13 Lorenzo Chiola 2018-12-05 15:55:07 UTC
Yes, only the custom theme breaks things in Libreoffice, as in comment #8.
> I guess we can close this as RESOLVED NOTOURBUG
Obv.
Have a nice day