I am unable to confirm the issue however there is more information in this forum thread:

http://en.libreofficeforum.org/node/10207/

Debian and OpenSuse distributions reported as affected and possibly related to gtk/qt.

For me not reproducible with LO 4.4.0.3, Win 8.1.  Therefore, as long as it is not confirmed by another user under a different OS I change the OS to Linux.

(In reply to Owen Genat from comment #1)
> I am unable to confirm the issue however there is more information in this
> forum thread:
> 
> http://en.libreofficeforum.org/node/10207/
> 
> Debian and OpenSuse distributions reported as affected and possibly related
> to gtk/qt.

Thomas: Perhaps you could invite one or more of the affected users to join us on this bug report? It would be great to know specifics about their environment including
- OS version
- LibreOffice version

Thanks!

I confirm this problem for LibreOffice from 4.4.0.3 onwards (up to the latest 4.4.2.1) on openSUSE 12.3 32-bit / KDE 4.5.11. In 4.3, this problem did not exist.

(In reply to DKG from comment #4)
> I confirm this problem for LibreOffice from 4.4.0.3 onwards (up to the
> latest 4.4.2.1) on openSUSE 12.3 32-bit / KDE 4.5.11. 

Status -> NEW

> In 4.3, this problem
> did not exist.

Keywords -> regression
Whiteboard -> bibisectRequest (I think bibisect might be useful here)

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

Maybe it is not really a duplicate of this bug, but i think it is the same systematic reason for the problem.

I have seen the same issue in Scientific Linux 6 i386 (essentially equivalent to RHEL6 and CentOS6) both for versions 4.4.0 and 4.4.1.  I have had to revert back to version 4.3.X both times.

Our users are seeing the same problem here with LibreOffice 4.4.1.2 on RHEL 6.6 and CentOS 6.6.  Had to downgrade back to 4.3.3.2.

Problem may only be present when running in a KDE login session.  Works fine for me so far when logged in with a GNOME session, but my testing there is minimal.

My experience with the latest LO 4.4.2.2 (official RPM installers from the LO web site) using openSuSE 13.1 (64bit), the latest KDE 4 SC (4.14.6):

- On my desktop PC (Fujitsu Esprimo, Core2Duo CPU), equipped with a Radeon HD4350 graphics card, everything works fine.

- On my laptop (Lenovo R61, Core2Duo CPU), using the built-in Intel 965GM graphics chip, the artifacts appear. I had to switch back to LO 4.3.6 which has only one minor glitch: In the startcenter, the icons on the right show a black background.

On both machines, Open GL rendering is turned off in the LO settings. However, in the KDE system settings, on the desktop PC the compositing type is set to OpenGL 3.1 whereas on the laptop it is set to OpenGL 2.0 as switching to 3.1 causes the compositing effects to become disabled.

One more observation: On both machines, I'm using the KDE "Oxygen" theme with packages "gtk2-engine-oxygen" and "gtk2-theme-oxygen" installed. Consequently, in the GTK system settings, I selected "oxygen-gtk" as GTK2 design.
On the desktop PC, LO dialogs show Ogygen style checkboxes (i.e. with rounded corners and a real checkmark inside when "checked"), whereas on the laptop, checkboxes appear (both with LO 4.4 and 4.3) as standard square boxes with a cross inside when "checked".

Same issues here, for libreoffice 4.4.0.x, 4.4.1.x, and the latest 4.4.2.2-2.  I have had to revert to 4.3 each time I've tried 4.4.x, as the UI elements - buttons, menus, etc. - are completely garbled.  No 4.3.x or prior releases ever had these issues on my system.

OS is CentOS 6.6 x86_64, patched nightly against the updates repo, current kernel is 2.6.32-504.12.2.  

Desktop is KDE, also currently using the Oxygen theme.

Video hardware is NVIDIA Quadro 600.  Drivers - nvidia downloaded, not opensource, driver version 346.35.  OpenGL/GLX works fine for other apps.

Same issue
Os - Fedora FC21

Hit the wrong button and ended update
OS - Fedora FC21 - upgraded right before the problem
CPU - Intel QX9650
Memory - 8 gb
Video - NVIDIA GeForce GT 630 with 2 gb video memory
Desktop gui - KDE 14.12.3  Androbit scheme

Hope this helps with environment where the problem occurs.
 
I would add an attachment but it looks the same as the one already attached.

I am seeing this issue on 2 machines. A desktop running Fedora 20 with LO 4.4.2.2 with an ATI graphics card and on an Intel I7 laptop with Intel graphics running Fedora 21. So far I have been unable to find any work round which makes this version of LO usable and have reverted to 4.3 on both machines as that does not have the issue.

I have today tried LO 4.4.3.3 in case it made any difference. It does not using Fedora 21 KDE I still have the problems with screen corruption. So I am still using 4.3 on all my machines.

As only a select group of users are seeing this it would be really great if one of you could bibisect the issue - it takes some time but we're here to help.

https://wiki.documentfoundation.org/QA/HowToBibisect

You can join us in our chat to ask questions and have us walk you through the process: http://webchat.freenode.net/?channels=libreoffice-qa

This will do a lot towards moving forward towards a solution. As no current member of QA who does bibisect can reproduce the issue....we really need one of you to assist.

Updating version to reflect the earliest version confirmed.

Also moving to Critical as we won't block a release just because a bug is affecting a subset of our user base.

Which first and last commits for bibisection would you suggest?

So Stuart already tried bibisecting it and could not reproduce it in the bibisect package (which is unfortunate). Good chance this one is notBibisectable

Yes I was unable to recreate doing a bibisect with Joel's help. I have tested with 4.3.7 and 4.4.0 beta1 and it fails on 4.4.0 beta1 using the normal downloads. What I have noticed is that the bibisect versions did not show the OpenGL options in the settings but this does show in the normal downloads. Because of the artefacts I am unable to set/reset anything in the Options dialogue with certainty so I have not been able to test knowing OpenGL is off in LO. This is the ONLY program I have any issues with on both Fedora 20 and Fedora 21, nothing else shows any problems with displaying its data. I am quite willing to do more testing if anyone can point me in the right direction to get closer to this issue. Is it possible to start LO with any parameter to force OpenGL off/on, or manually edit any config file to set/reset this? It does seem to me to be a display issue and therefore OpenGL could be part of the problem. I have checked Fedora 22 and it will have LO 4.4 as default when it is released next week and I will test that version then.

Created attachment 116141 [details]
Sporadic Error in Version 4.3.6.2

It's crazy but now i got this error in Version 4.3.6.2.
But only one time and it's not reproducible.

I am working with this version now because the error did not occur up to now.
It was interesting that this error can happen in this version also.

Can someone try with LibreOffice 5.0 daily and report back ? 

http://dev-builds.libreoffice.org/daily/master/

At this time i can only test with a ready build package.
Best as deb but a version to simply unpack would be enough.

It's not needed to have the complete office.
The artifacts will appear already on the (main) start window.

The packages are "ready" and "build" (i.e. the debian/rpm binaries) are in that link that I provided :) If you head over there you'll see sub folders that have the already build packages.

O.K. I did read "...archive.tar.gz" with 1,6 GB and thought it would be the source.
I try to download, unpack and test http://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@46-TDF-dbg/current/master_dbg~2015-05-30_08.16.13_LibreOfficeDev_5.1.0.0.alpha1_Linux_x86-64_archive.tar.gz

Today having tested Fedora 22 under virtualbox and found LibreOffice ran OK I decided to install Fedora 22 on my same laptop where I had these problems. Initially I ran the official LibreOffice install (4.4.3.2) from the Fedora repositories and all worked OK as it had in the virtualbox system. Next I removed the official install and ran an install using the exact same copies of the downloaded rpms for 4.4.3.2 and once again LO runs with NO artefacts on screen with or without OpenGL activated.

So I'm now unsure about the cause of this problem. Fedora 22 does use KDE Plasma 5. I still have the problem on my KDE4 Fedora 20 desktop PC. Could there be an incomatability between LO 4.4 and something in the Fedora 20 and 21 system both of which run KDE4 Plasma desktop?

Created attachment 116192 [details]
Test with LibreOfficeDev_5.1.0.0.alpha1_Linux_x86-64 daily

Here is the test result with the daily version.

Anything additional to test?
I will wait before i delete it.

Thanks so much for testing it - nothing else to test there.

@Karsten - what distro are you running? With Stuart's findings I'm thinking maybe it is NOTOURBUG...

I have documented it here:
https://bugs.documentfoundation.org/show_bug.cgi?id=89711#c5
Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux

I can understand that you hope that this is not your bug. :-)
But why older versions are working without this problem?
Of course the reason maybe could be find in the distribution, but it would be fine if newer versions would run like the older before.

It's just a possibility. It is a misunderstanding to think "just because it worked before it will work now the same way." Our code is incredibly complex - maybe before something in the code made it so the bug in a distro didn't show but now our code got "fixed" and so the bug in the distro (or some particular package in the distro) shows up. Again, this is just a guess. As I said, code is really complex (far too complex for me to know what is going on here). But - one of the people who were experiencing this bug before no longer experiences it now that they are on Fedora 22 (Fedora 21 showed it). Maybe it's a simple dependency issue and your package manager has not updated a necessary package for openGL to function properly.

Created attachment 116209 [details]
LibreOfficeDev_5.1.0.0.alpha1_Linux_x86-64 with opengl disabled

I agree your argumentation.
Again i tested what happened when i disable hardware acceleration / opengl.
The problem remains.
So it must be a general problem of the rendering.

I hate to say this in some ways but the problem has come back on my Fedora 22 laptop and I dont know why. Obvioulsy being fairly new there have been some changes recently to F22 and I do keep up to date. Anyway the problem has re-surfaced. This is using KDE Plasma 5 on F22 and running the downloaded versions of LO. I will remove these and re-install the official Fedora RPMs to see if anything changes.

Just tested the official Fedora RPMs for LO and it is working. Hwever what I would say is that the window and associated decorations look significantly different, by that I mean the icons fonts used and buttons etc are very different from the LO RPM version.

Maybe it is a combination of X, NVidia driver and Office?

There where many problems when i try to update from Debian stable to testing.
The newer X-Server and NVidia-driver did have problems to fit together.

With less ~/.xsession-errors i can find this for me:

OpenGL vendor string:                   NVIDIA Corporation
OpenGL renderer string:                 GeForce GT 430/PCIe/SSE2
OpenGL version string:                  4.2.0 NVIDIA 304.125
OpenGL shading language version string: 4.20 NVIDIA via Cg compiler
Driver:                                 NVIDIA
Driver version:                         304.125
GPU class:                              GF100
OpenGL version:                         4.2
GLSL version:                           4.20
X server version:                       1.12.4
Linux kernel version:                   3.2
Direct rendering:                       yes
Requires strict binding:                no
GLSL shaders:                           yes
Texture NPOT support:                   yes

Only thing I would say is that my desktop which does not work with 4.3 has AMD CAICOS graphics card and my Laptop has Intel so I'd guess more to do with x or OpenGL rather than graphics drivers/cards.

(In reply to Stuart Rogers from comment #35)
> Only thing I would say is that my desktop which does not work with 4.3 has
> AMD CAICOS graphics card and my Laptop has Intel so I'd guess more to do
> with x or OpenGL rather than graphics drivers/cards.

That should say 4.4 !!!

I’ve upgraded my system from openSUSE 12.3 32-bit / KDE 4.5.11 to openSUSE 13.2 64-bit / KDE 4.14.2 (on the same machine, no hardware changes). The problem is gone, at least in LO 4.4.3.2 64-bit.

Dear everyone.

I had same bug and toolbar black out bug using LO 4.4.3.2.
My system is Debian 7 with KDE 4.8.4.

LO 4.3.x.works fine,but update to LO 4.4.3.x this bug appears.

I read this bug report,and I guess it occur in using KDE. 
Then I used GMOME,LO works normal.

Next I found package depend on KDE in LO install packages.
It is in /LibreOffice_4.4.3.2_Linux_x86-64_deb/DEBS/
libobasis4.4-kde-integration_4.4.3.2-2_amd64.deb.

I uninstalled this package,LO works fine.

Best regards.

Created attachment 116549 [details]
Problem of artefacts in libobasis4.4-kde-integration

I tried now a "aptitude purge libobasis4.4-kde-integration".
Yes - the artifacts has gone!
This should narrow the problem.

But now i can work with libreoffice only in full screen with this version.

I upgraded my system now to the actual stable release of Debian stable 8.0 (Jessie).
This is using KDE 4.14.2
Here the artifacts does not appear when i reinstall libobasis4.4-kde-integration.
This will solve my problems.

let's set status to RESOLVED WORKSFORME then.
feel free to revert it if you think I'm wrong.

I've also added "KDE specific" to summary notes

Removing libobasis4.4-kde-integration does not seem to fix the problem on RHEL6/CentOS6.  

Interestingly, the corrupt visual elements do change a bit - instead of "glitched" multicolor patterns that render most items intermittently unreadable, the items that were previously glitched are now just black and completely unreadable.

I've also confirmed that setting UseOpenGL to false (vs. leaving it set to true) in the registrymodifications.xcu file seems to have no effect on the glitched graphics.

That's interesting about KDE integration, in the Fedora 21 repositories there is an equivalent RPM available but by default on my 4.3 installs it is not installed, neither is it on my F22 system.

I will try the 4.4 rpms again on both F22 and F21 but this time without the libobasis4.4-kde-integration and see what happens, I will also try adding the kde support rpm for Fedora to the distros install and see what happens. This may take a few days before I report back

Well on my F21 system I just installed the LO RPMs for 4.4.3.2 having first removed libobasis4.4-kde-integration from the base install and it does indeed work OK on my system without this. I will later try F22 to see what happens, maybe on that I'll try the Fedora KDE RPM first to see before trying the later release.

Just tested F22 with the Fedora KDE rpm and it works perfectly with that. Not totally surprising because I'd expect it to be quite well tested prior to release.

Next I removed the Fedora version and installed the LO rpms minus libobasis4.4-kde-integration rpm and once again it seems to work fine. 

Later on my F22 system I will try installing libobasis4.4-kde-integration to see if the bug comes back, and then if it does remove it again and see if it goes away. I am a bit worried about any more F21 testing because that is my main system which I use and need a working LO install.

let's put it back to RESOLVED WORKSFORME
again, feel free to reopen if the bug strikes back.

That's a bit frustrating a transition, since I don't feel like we've found a fix for this that's consistent nor a reason for the bug. The title even says "RHEL6 KDE-specific", but we haven't yet found a fix for RHEL6! I haven't seen any comments from any other RedHat users that anything's getting us closer to a solution.  All of the "WORKSFORME" solutions so far have been on Fedora or Debian.  

Should we open a new bug for the RHEL/CentOS users out there?  Some of us don't have the option to switch to Fedora or Debian.  "WORKSFORME" is specific to some users, but others of us on CentOS are still stuck on 4.3.x and can't upgrade to 4.4 until we are able to sort out what's triggering this bug, so the bug isn't really fixed.

I am not sure this is fixed for Fedora users. Not installing one of the rpms is a work round but it is NOT a fix. There has to be something in the rpm which is causing bad integration with KDE. I hope the devs take this seriously and start investigating the code in the rpm. The lack of the rpm does cause some minor headaches when using LO on a KDE system, OK nothing major but we should be able to install the product as shipped and have it work.

Ok. you are right. let's put it back to NEW.

There is a lot of confusion here, so to clarify it a bit:

* The libobasis4.4-kde-integration package (downloaded from libreoffice.org) is the integration for KDE3, it shouldn't have any effect under KDE4/5 (unless someone forces using it with a env. variable). Official packages don't have KDE4 integration at all (although it might change in the near future). Users of the official packages are actually using the GTK integration (found in libobasis4.4-gnome-integration), so this bug is about some interaction between the GTK integration and oxygen-gtk theme, or even some bug in oxygen-gtk itself.

* The libreoffice-kde package from Fedora repos is for KDE4, so it doesn't make much sense to compare its behavior with the official packages. One has to remove it, or force the GTK integration with OOO_FORCE_DESKTOP=gnome, or at least SAL_USE_VCLPLUGIN=gtk, to do the comparison.

"...is the integration for KDE3, it shouldn't have any effect under KDE4/5..."

But it has effect as you can see.
You should search for the problem here.

(In reply to Karsten from comment #51)
> "...is the integration for KDE3, it shouldn't have any effect under
> KDE4/5..."
> 
> But it has effect as you can see.
> You should search for the problem here.
But if you don't use KDE3, you shouldn't install this rpm at all.

(In reply to Maxim Monastirsky from comment #52)
> (In reply to Karsten from comment #51)
> > "...is the integration for KDE3, it shouldn't have any effect under
> > KDE4/5..."
> > 
> > But it has effect as you can see.
> > You should search for the problem here.
> But if you don't use KDE3, you shouldn't install this rpm at all.

Well I have never seen this anywhere, at least no where obvious. I suspect that this problem MIGHT be caused because you can have some KDE3 libraries installed on a KDE 4 system in order to run some older applications. My old F20 system probably did have some KDE3 libraries on it but the new F21 and F22 system do not have any KDE3 stuff installed currently as they were both clean installs and not an upgrade so this will have cleaned out any old libraries.

Since this rpm is not needed to run LO on a KDE4 system then I'd suggest it be removed from the download on the LO website.

Interestingly the Fedora KDE LO package does not install when you install the Fedora LO packages even on a KDE4 system (or for that matter on a KDE Plasma 5 system).

(In reply to Maxim Monastirsky from comment #52)
> But if you don't use KDE3, you shouldn't install this rpm at all.

There are to many packages!
As i remember i already suggested to reduce them to get an overview. ;-)
Where do i know which must be installed?

When you deliver them all i must think that all of them must be installed.
Is there a descripton which package is needed for which purpose?

But back to the problem.
Why the window management does not work correctly after deleting the package?
I think it's obvious that something is going wrong here ...

(In reply to Stuart Rogers from comment #53)
> I suspect
> that this problem MIGHT be caused because you can have some KDE3 libraries
> installed on a KDE 4 system in order to run some older applications.

Yes - that's possible.
My system has been upgraded several times to keep all installations and settings.

Then Libreoffice should check which KDE version is actually running.
Maybe it is a good idea to check this in the installation scripts of the packages also.

I find to interesting links:

http://www.kde-forum.org/artikel/15751/how-to-check-kde-version-using-command.html

http://www.commandlinefu.com/commands/view/10061/get-kde-version

(In reply to Karsten from comment #55)
> Then Libreoffice should check which KDE version is actually running.
It already checks, but there might be a bug somewhere in this code.

Would be useful to know whether running LO with OOO_FORCE_DESKTOP=gnome exported makes any difference (with KDE3 rpm installed)? If yes - then it must be a bug in the detection code.

I'd like to know how LO checks for KDE version. On my KDE4 system (F21) kded --version shows KDE 3 but konsole --version shows KDE 4. Thing is not all KDE components are updated unless required as shown by my test. It cold well be dependent on how you check for the KDE version.

(In reply to Stuart Rogers from comment #58)
> I'd like to know how LO checks for KDE version.
It checks various env. variables like DESKTOP_SESSION, XDG_CURRENT_DESKTOP, KDE_FULL_SESSION and KDE_SESSION_VERSION.

But I think I found something:

After LO detects the KDE4 desktop it tries to initialize the GUI plugin using the following fallback list:

    static const char* const pKDEFallbackList[] =
    {
#if ENABLE_KDE4
        "kde4",
#endif
#if ENABLE_KDE
        "kde",
#endif
        "gtk3", "gtk", "gen", 0
    };

This means that when building without KDE4 support (i.e. ENABLE_KDE4 is not defined), the first plugin that it tries to load is the KDE3 one.

Another thing I found is a report from a KDE3 user, with similar symptoms - Bug 92412. So it could be that what you're using is actually the KDE3 plugin, and this one has the bug.

But still - I would like to hear if exporting OOO_FORCE_DESKTOP=gnome makes any difference.

(In reply to Maxim Monastirsky from comment #59)

> But still - I would like to hear if exporting OOO_FORCE_DESKTOP=gnome makes
> any difference.

I booted my old Installation now for you.
The problem is that i purged the package and the artifacts has gone.
So it makes no difference.
But here the content of the variables:

$ set | grep -i kde
DESKTOP_SESSION=kde-plasma
GTK2_RC_FILES=/etc/gtk-2.0/gtkrc:/home/karsten/.gtkrc-2.0:/srv/ssd1/home/karsten/.kde/share/config/gtkrc-2.0
GTK_RC_FILES=/etc/gtk/gtkrc:/home/karsten/.gtkrc:/srv/ssd1/home/karsten/.kde/share/config/gtkrc
KDE_FULL_SESSION=true
KDE_MULTIHEAD=false
KDE_SESSION_UID=1000
KDE_SESSION_VERSION=4
QT_PLUGIN_PATH=/srv/ssd1/home/karsten/.kde/lib/kde4/plugins/:/usr/lib/kde4/plugins/
        COMPREPLY=($( compgen -W "add autoinstall remove build install uninstall                        match mkdriverdisk mktarball ldtarball mkrpm mkdeb mkdsc mkkmp                     status" -- $cur ));


$ set | grep -i ooo
OOO_FORCE_DESKTOP=gnome

(In reply to Karsten from comment #60)
> KDE_FULL_SESSION=true
> KDE_SESSION_VERSION=4
That's enough for LO to detect the session as KDE4. So as much as libobasis4.4-kde-integration can be involved, it seems to be related to the fallback list I mentioned in comment 59 (and that would happen only if the system has KDE3 libs).

But the fact that some reporters here explicitly mentioned oxygen-gtk, makes my wonder whether there is another similar bug with oxygen-gtk, and we're mixing in this thread two completely unrelated bugs?

This could be true.
I am using oxygen also.

But is it possible that an KDE decoration design is responsible for this effects?
This should be tested by someone who has actually the problem live.

OK so on my F22 system which shows KDE as version 5 I re-installed the kde integration rpm and yes the artifacts do indeed come back. I also checked and although I was using Oxygen I am not using the GTK but the QT5 version. I changed it to the standard Fedora 22 layout in desktop theme, I also tried Air and Breeze and everytime I get the artifacts.

OK: 
Exporting OOO_FORCE_DESKTOP=gnome
and then starting LO from that shell resolves the problem on RHEL6 – no more strange artifacts!

When I start LO from a shell where I didn't export that variable, I see the artifacts and I get 18 warnings in the console:

libpng warning: Application built with libpng-1.2.44 but running with 1.6.16

I suspect this to be the root cause of the artifacts. I wonder why I hadn't noticed these before…

Created attachment 117074 [details]
Problem opening Libreoffice the first time

When i open V 4.4.3.2 the first time there is the strange effect that the icons are inverse/black.
When i open a document and close it the icons are shown normal.

So something is not fine here in the actual Debian stable also.

@karsten
your latest screenshot reminds me this old bug:
Bug 79147 - Transient / HiContrast theme mis-selection race on start

(In reply to thomas from comment #64)
> Exporting OOO_FORCE_DESKTOP=gnome
> and then starting LO from that shell resolves the problem on RHEL6 – no more
> strange artifacts!
Thank you thomas for the valuable input. So this proves again that the bug is in the KDE3 stuff. And I also can confirm it now under F22 with the KDE3 vclplug.

> your latest screenshot reminds me this old bug:
> Bug 79147 - Transient / HiContrast theme mis-selection race on start

Yes - and it has been not fixed.
But it's no problem to live with this little problem.

It looks general for a problem that appears only under certain circumstances.

Confirmed here, as well, for CentOS 6 w/ KDE 4 and Oxygen theme: Exporting OOO_FORCE_DESKTOP=gnome fixes the artifact issue completely for LibreOffice 4.4.3.2.

Interestingly, unlike thomas@mitterfellner.at, though, I don't see the libpng errors on the console when running LO 4.4 without the variable exported.

Thanks all, for sticking with this bug report - I'm glad to see we're making progress, have a legitimate workaround, and an idea of where the bug is in the code.

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

(In reply to Maxim Monastirsky from comment #70)
> *** Bug 90437 has been marked as a duplicate of this bug. ***

These "artifacts" made LO 5 unusable under KDE. So raising importance.

Best regards. JBF

(In reply to Jean-Baptiste Faure from comment #71)
> These "artifacts" made LO 5 unusable under KDE. So raising importance.
Note that this is no longer an issue for 5.1, since we get KDE4 support in [1]. As for 4.4/5.0, there is an easy workaround with either SAL_USE_VCLPLUGIN or OOO_FORCE_DESKTOP exports (the latter is recommended anyway, as it will make also SMB support work), or simply by not installing the KDE3 package.

[1] http://cgit.freedesktop.org/libreoffice/core/commit/?id=420be486f04d99b08311151a4230699099184baa

(In reply to Maxim Monastirsky from comment #72)
> ... or simply by not installing
> the KDE3 package.

This is not so simple to say.
When you have an upgraded migrated system you don't know about artifacts of older systems.
The same problem is that you NEED some older parts for some applications you don't want to miss like Libreoffice.

So the best solution would be that Libreoffice is more tolerant to all kind of installations.

(In reply to Karsten from comment #73)
> When you have an upgraded migrated system you don't know about artifacts of
> older systems.
You missed my point. No one ever said that it's expected to have this problem with KDE3 libs. But given that there is such problem right now, one possible *workaround* is to remove the KDE3 support.

> The same problem is that you NEED some older parts for some applications you
> don't want to miss like Libreoffice.
Then you can keep the system KDE3 libs, and remove only the LibreOffice KDE3 support.

> So the best solution would be that Libreoffice is more tolerant to all kind
> of installations.
Again - the problem is not that LibreOffice can't handle some installation, but that there is a bug in the KDE3 code, which we're trying to workaround by using something else.

Added target, and lowered the importance a bit (there is a workaround, and having KDE3 libs on modern Linux installation is quite uncommon anyway.)

Yes - i understand and agree.

But you can see that this bug will follow you through all versions of KDE.
It will not help to wait in hope that it will disappear.
That's what i want to say.

The problem still shows up in LibreOffice 5.0

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

Created attachment 117891 [details]
screenshot on first use of writer

version 5.0.0.5 direct from LibreOffice web site as rpms for Fedora 21 (32bit) with KDE desktop

reverted to version LibreOffice 4.1.5 (rpms from LibreOffice download) and problem goes away.

After encountering GUI artefacts when using Libreoffice 4.4.1, KDE and CentOS 6.6 and  Libreoffice 5.0.0, KDE and CentOS 6.7, I re-installed Libreoffice 5.0.0 after
removing libobasis5.0-kde-integration-5.0.0.5-5.x86_64.rpm from the RPMS directory, and the artefacts are gone.

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

I can confirm the bug for LO 4.4.5.2 and LO 5.0.1.2 under Ubuntu 12.04.5 and TDE 3.5.13.2

Comment #81 from Angelika (removing libobasis5.0-kde-integration) solved the issue. 
This worked also with LO 4.4.5.2
But the effect is of course, that the TDE fileselector is replaced by the LO version...

This is collaterally fixed by removing KDE3 support with:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=72699595aaa3ecb8975050b6dfc6fde437770493

on master.

Comment #81 from Angelika (removing libobasis5.0-kde-integration) solved the issue.

I can confirm that removing libobasis7.1-kde-integration (7.1.8.1-1) helps for
Version: 7.1.8.1 / LibreOffice Community
Build ID: e1f30c802c3269a1d052614453f260e49458c82c
in Debian 12 (bookworm)

My last comment is showing that this issue has not been fixed!

Created attachment 193259 [details]
Glitch window dialog in flatpak version

Created attachment 193266 [details]
Normal window in deb version

Hello misters ,i'm simllar problem on flatpak version in Linux ,but it's a on the newest version 24.2 ,but on the deb version 7.3.7.2 i don't have that issue. reset user profiles doesn't exits. the kernel version seriously new(6.5).
Environment: Linux Mint Cinnamon Desktop.

(In reply to Dariusz from comment #97)
> Created attachment 193266 [details]
> Normal window in deb version
> 
> Hello misters ,i have simllar problem on flatpak version in Linux ,but it's a
> on the newest version 24.2 ,but on the deb version 7.3.7.2 i don't have that
> issue. reset user profiles doesn't exits. the kernel version seriously
> new(6.5).
> Environment: Linux Mint Cinnamon Desktop.

Back to RESOLVED FIXED as KDE3 support has been removed.

For flatpack version, please open a new bug report.

Best regards. JBF