Created attachment 109911 [details]
First screen with black menues
I have opend LO 22.214.171.124beta1 on OpenSUSE 12.3 64bit. Have also installed a lot of other LO-versions. I couldn't chose any entry in the menu because the menu is totally black. Then I started a database-file and get a screnn with some damaged icons and black menuline above.
This version of LO seems to be unusable here.
I started LO on KDE. No version of LO does show such a behavior up to LO 126.96.36.199alpha. Beta1 is the first ...
Created attachment 109912 [details]
Second screen of Base-file with black menu and damaged icons
looks like a duplicate of Bug 79147 - Transient / HiContrast theme mis-selection race on start
try changing Linux theme and see if it fix things.
it seems there's some conflict between some Linux and Windows themes.
*** This bug has been marked as a duplicate of bug 79147 ***
(In reply to tommy27 from comment #2)
> looks like a duplicate of Bug 79147 - Transient / HiContrast theme
> mis-selection race on start
> try changing Linux theme and see if it fix things.
Isn't a duplicate. When I start ICEWM or XFCE, the wrong high-contrast-theme appears the first time. The menue isn't black.
When I open it under KDE 4.10.5 the menue disappears and the high-contrast-theme appears. I open a file and close the file (click on the black right upper corner of the window, where the 'x' should be) and the wrong theme has been gone - but the black background for menu is already there.
Ok, I revert status to UNCONFIRMED
Please read this message in its entirety and do not revert change.
This is simply an update to the priority/severity of the bug. Blockers are reserved for incredibly rare cases which this bug does not meet. We use an objective standard of what is or is not a blocker and this does not count as a blocker.
Normal - this is just a normal bug...nothing particularly special about it.
High - regression.
Again please do NOT change the severity back as it does not help at all in pushing the bug forward and instead only confuses our objective standards - leading to developers not trusting the system. Setting to blocker will have zero impact towards moving the bug forward.
Thanks for your understanding.
(In reply to Joel Madero from comment #5)
> Please read this message in its entirety and do not revert change.
> This is simply an update to the priority/severity of the bug. Blockers are
> reserved for incredibly rare cases which this bug does not meet. We use an
> objective standard of what is or is not a blocker and this does not count as
> a blocker.
This has been the first time I set a bug to "BLOCKER". Who will decide it isn't? I couldn't test this version of LO in my desktop-environmemt, because I couldn't see anything in the menue.
This version is unusable for me. There are many regressions in bugs I have reported. The regressions are set to "medium" - because I could work with a workaround. But with this regression I couldn't work at all.
So it definitely isn't based on "this prevents ME from using the software." Blockers must be discussed thoroughly within QA, then presented to the ESC to determine if it is indeed a blocker...to be honest in 3 years I think I've seen 2-3 blockers....it is very rare.
For more information you can see:
Basically we need solid proof that this affects a wide (very very wide) amount of people, affecting multiple platforms, and essentially completely preventing (lots) of people from using the software. That is the only time we'd block a release.
(In reply to robert from comment #0)
> I have opend LO 188.8.131.52beta1 on OpenSUSE 12.3 64bit. Have also installed a
> lot of other LO-versions. I couldn't chose any entry in the menu because the
> menu is totally black. Then I started a database-file and get a screnn with
> some damaged icons and black menuline above.
> This version of LO seems to be unusable here.
NOREPRO with LO 184.108.40.206.beta2 + Ubuntu 14.04 (64bit) + Unity.
> I started LO on KDE. No version of LO does show such a behavior up to LO
> 220.127.116.11alpha. Beta1 is the first ...
Hmmm...I had no issues w/previous builds either.
(In reply to robert from comment #3)
> Isn't a duplicate. When I start ICEWM or XFCE, the wrong high-contrast-theme
> appears the first time. The menue isn't black.
If I understand correctly:
1) You have issues under multiple WMs
2) For ICEWM and XFCE, the issues only appear the first time you load LibreOffice (?)
3) The worst behavior (e.g. with black menu) is under KDE
Question: Do you have a high-contrast theme enabled? (intentionally)
(In reply to Robinson Tryon (qubit) from comment #9)
> If I understand correctly:
> 1) You have issues under multiple WMs
> 2) For ICEWM and XFCE, the issues only appear the first time you load
> LibreOffice (?)
This is https://bugs.freedesktop.org/show_bug.cgi?id=79147. It appears with every WM here. Not the black menue.
> 3) The worst behavior (e.g. with black menu) is under KDE
Yes, but only with OpenSUSE 12.3 64bit rpm. Tested it with OpenSUSE 13.1 64bit rpm on another system - there the black menu (and also the high-contrast-theme when opening first time) doesen't appear.
> Question: Do you have a high-contrast theme enabled? (intentionally)
The enabled theme is oxygen. Have opened both systems and switched all to the same behavior in KDE - but couldn't get away the black menu (and also the high-contrast-theme when opening first time).
The difference between both systems: There are some other WMs installed on the system with the buggy behavior. Had to install this WMs for getting the right screenshots for LO-Base-Handbook in Germany.
Confirmed w/ openSUSE 13.1, KDE4 de 4.11.5, LibreOfficeDev_18.104.22.168.beta1_Linux_x86-64_rpm installed in parallel w/o desktop integration
changed importance according to flowchart as it makes LibO totally unusable and happens at every launch.
However prio only to HIGH (and not to highest) as only one platform seems to be affected (so far)
Adding self to CC if not already on
Let's put this on MAB list if it's so critical.
For those of you seeing this problem, a bibisect would be really helpful to get it fixed...
I'm still not convinced that this is a blocker, nor am I convinced that the problem has been clearly described...but none the less a bibisect would help. https://wiki.documentfoundation.org/QA/HowToBibisect
(In reply to Joel Madero from comment #15)
> For those of you seeing this problem, a bibisect would be really helpful to
> get it fixed...
> I'm still not convinced that this is a blocker, nor am I convinced that the
> problem has been clearly described...but none the less a bibisect would
> help. https://wiki.documentfoundation.org/QA/HowToBibisect
Problem: All users, who could confirm this bug, use OpenSUSE. If I understand it the right way bibisecting isn't possible with OpenSUSE.
Next problem: The bug doesn't appear on every OpenSUSE-installation. Could be the same OpenSUSE-installation on other hardware would work right with LO 4.4.*
(In reply to Joel Madero from comment #15)
> I'm still not convinced that this is a blocker, nor am I convinced that the
> problem has been clearly described...
+10000. Why was this added to MAB?
Because others have a different opinion and it's good to respect those too ;) Seems like for some people this bug makes LibreOffice literally unuseable. That being said - I'd prefer lowering it to major-highest, but I've already done enough fiddling with this bug....
So please write down, what should be described better. I have added screenshots, which would show the problem. I wrote down the system where the bug appears. This is a system, where all version up to 22.214.171.124 alpha wouldn't show this error. First apperas with 126.96.36.199.Beta1.
... and with this buggy behavior LO is totally unusable with the system I described. Or is there anybody, who would say: "Black menues - doesn't matter, I know all the shotcuts, and know where to press with the mouse. Buttons mustn't have a description."?
(In reply to robert from comment #19)
> So please write down, what should be described better.
It would be great to check the 4.5 (i.e. master) branch to confirm the problem there as well. If it's not present there, that'll definitely help us track down the problematic commit(s).
Feel free to grab a build from this tinderbox:
Reproducible with Master: 188.8.131.52.alpha0+ Build ID: b3c6f2765602290fecd1f1e291e11667b6b446b6
Branch:master, Time: 2015-01-09_23:42:42
installed in parallel w/o desktop integration on openSUSE 13.1, KDE4 de 4.11.5
If there are special criteria (eg SUSE of KDE) can that then be please added to the summary? IS really convenient for others looking in/through bugs. thanks :)
(In reply to Cor Nouws from comment #22)
> If there are special criteria (eg SUSE of KDE) can that then be please added
> to the summary? IS really convenient for others looking in/through bugs.
> thanks :)
We have tried to look for this special citeria:
OpenSUSE: Bug appears with 12.3 and 13.1 64bit - but not every time. I had a netbook with 31.1 64bit and it worked well.
KDE: Bug appears on both systems only with KDE, not, for example, with xfce. But if you start xfce on this systems, you could see in XFCE the high-contrast theme, when you start LO (Bug79147). This doesent appear on systems, where this bug also doesn't appear.
We have also searched for graphic cards - aren't the same on systems with the bug (Intel, Radeon).
Have updated my system to OpenSUSE 13.2 and openend LO 184.108.40.206 again. Seems the bug has gone there - don't know why.
220.127.116.11 still unusable in my environment (see comment#12)
Created attachment 113047 [details]
RHEL-6 (Scientific Linux 6.6) black menus
See RHEL-6.6-LO-88686.txt for system details.
Created attachment 113048 [details]
RHEL-6 (Scientific Linux 6.6) black menu, system details
System details for screenshot RHEL-6.6-LO-88686.jpg
Problem confirmed for Scientific Linux 6.6 (clone of RHEL 6.6, all TUV patches applied).
Window Manager: TUV original KDE KWin 4.3.4
NVidia Quadro NVS 300 and NVidia binary drivers (from ELrepo, 340.65)
Xorg-X11 7.7: Option "AIGLX" "True"
Version has to be the first the bug appears. First version is LO 18.104.22.168beta1 - see description of this bug.
Checked for RHEL-7 (Scientific Linux 7.0): Bug does not show up here.
Created attachment 113120 [details]
Grafic errors on openSUSE 13.2 64-bit
On openSUSE 13.2 64-bit, KDE 4.14.4 i see a lot of grafic errors on the menus.
Please don't manipulate the severity/importance. This is not a blocker. Moving back to critical.
*** Bug 89407 has been marked as a duplicate of this bug. ***
Please note that LO is completely unusable for me, I had to downgrade to 22.214.171.124
I reproduced the problem on two fully updated CentOS 6.6 systems on which stock KDE packages are installed.
126.96.36.199-2.x86_64 does not fix the problem on Scientific Linux release 6.6 (Carbon) x86_64.
Same problem under CentOS 6.6, KDE with LO 188.8.131.52: menus and UI components are black or *completely* messed up, impossible to work.
1. export OOO_FORCE_DESKTOP=none
2. make sure the two options "Use OpenGL for all rendering" and "Force OpenGL even if blacklisted" are disabled.
This will provide no-frills, ugly but working UI on KDE.
@irisx: thanks! Your workaround works well in my environment (see comment#11) for both 184.108.40.206 and Master-20150110
Removing comma from Whiteboard (please use a space to delimit values in this field)
Since reports show this to be inconsistently reproducible even on the same OS (Linux), this needs to be assumed to be caused by buggy graphics drivers. Closing as NOTOURBUG, please refer this to the Xorg maintainer of your distro first. Reopen this bug only, if there is qualified proof these display errors are caused by illegal/insensible requests of LibreOffice from the display server.
I find it rather hard to believe that it's a problem with the drivers of the distro given that I can reproduce the bug on 3 completely different systems
- one AMD based with a separate NVIDIA Corporation GT218 based video card, using NVidia's drivers
- one AMD based with onboard video, using ATI's drivers on a Radeon HD 8570D
- one MSI B75MA-P45 with integrated Intel video; this is the only system which runs the drivers provided by the distribution.
Migrating Whiteboard tags to Keywords: (bibisectRequest)