Bug 74416 - KDE filedialogs get extremely slow after using copy action in one of LOs components
Summary: KDE filedialogs get extremely slow after using copy action in one of LOs comp...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
4.2.3.3 release
Hardware: Other Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:4.2.3
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-02 21:10 UTC by Franz Fellner
Modified: 2014-04-25 14:35 UTC (History)
5 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 Franz Fellner 2014-02-02 21:10:13 UTC
To reproduce:
* Make sure no libreoffice instance is running
* Also make sure that you are actually using the kde file dialogs
* Start e.g. writer
* write some text
* select it
* trigger "copy" (ctrl+c, context menu etc.)
* press e.g. "open document"
The dialog takes ages to pop up, navigating to other directories will take ages. It happens that selecting one single file takes more than one minute.
Also notice that there is no high CPU usage, so looks like a locking issue.
Comment 1 Tobias Leupold 2014-02-02 21:16:08 UTC
I can exactly reproduce this with Libreoffice 4.1.4.2 on my Gentoo System.
Comment 2 Maxim Monastirsky 2014-02-02 21:33:00 UTC
Same here under Fedora 20, with both 4.1.4 and master (Build ID: 1a37a61be4a39079d6e9fa671d04036a56510281).
Comment 3 Franz Fellner 2014-02-04 13:40:21 UTC
An interesting observation by firefly in the german Gentoo forums:
http://forums.gentoo.org/viewtopic-p-7493666.html#7493666
If you open another application (firefox, text editor, ...) and copy some text the file dialogs start to respond quickly as usual again.
firefly says it is related to the Clipboard selection type ownership.
Comment 4 Jan-Marek Glogowski 2014-02-07 09:46:12 UTC
This is a "regression" introduced by 13a34f4c6307d1bd2443cbf3fbd83bfdd8cdbafb to fix #69002.

Currently I don't know how to fix it.

I might need to implement something like 1c7d90a8f9a38b166168468bed60405ef6e26493 for clipboard polling - somehow.

Without 13a34f4c6307d1bd2443cbf3fbd83bfdd8cdbafb I get - again - crashes with KDE4 file dialogs - mmpf.

I actually wanted to implement a correct fix, but got no reply to https://bugreports.qt-project.org/browse/QTBUG-34614. 13a34f4c6307d1bd2443cbf3fbd83bfdd8cdbafb is actually more of a workaround then a real fix.

I hope to find a solution today but unfortunately I won't be able to look into this problem next week.
Comment 5 Maxim Monastirsky 2014-02-07 10:11:54 UTC
(In reply to comment #4)
> This is a "regression" introduced by
> 13a34f4c6307d1bd2443cbf3fbd83bfdd8cdbafb to fix #69002.
Not sure, since it's reproducible even with 4.1.4 which doesn't have that commit AFAIK.
Comment 6 Jan-Marek Glogowski 2014-02-07 13:53:16 UTC
I tested the reverted patch on master.

(ok I just added the 

  m_pApplication->clipboard()->setProperty( "useEventLoopWhenWaiting", true );

line ).

This did help, but reintroduces the crashes.

I assumed everybody used distro (e)builds and I've heard Gentoo backported the KDE4 patches.
Comment 7 Andreas K. Hüttel 2014-02-08 11:59:54 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > This is a "regression" introduced by
> > 13a34f4c6307d1bd2443cbf3fbd83bfdd8cdbafb to fix #69002.
> Not sure, since it's reproducible even with 4.1.4 which doesn't have that
> commit AFAIK.

Gentoo LO team here. Gentoo 4.1.4 has it, was backported (only cosmetic changes needed). Maybe Fedora too?
Comment 8 Jan-Marek Glogowski 2014-03-03 11:33:02 UTC
Ok - I've pushed 380f3b4b6cbbe8e82b58ddf55e95c5005307b51f to master. Not really a fix, but it seem to make things better.

I've also added a backport for 4.2 to https://gerrit.libreoffice.org/#/c/8435/.

Should also apply to 4.1, if you have all the previous patches.

Hint, hint: there is private/jmux/libreoffice-4-1+fixes...
Comment 9 Commit Notification 2014-03-05 14:27:22 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "libreoffice-4-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=e95d5d52c84c073e1878c290031cdde6061fcc7d&h=libreoffice-4-2

fdo#74416: sleep in yield for native file picker


It will be available in LibreOffice 4.2.3.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 10 Peter Lemieux 2014-03-14 02:38:13 UTC
The version I downloaded from the Ubuntu PPA for LibreOffice, 1:4.2.2~rc1-0ubuntu1~ppa1, apparently includes this fix.  File dialogs were incredibly slow using the version currently in the repositories for the upcoming 14.04 (Trusty) beta release.  Adding the PPA and upgrading eliminated the problem.  Thanks to all involved for this patch!
Comment 11 jose.velez 2014-04-23 09:55:05 UTC
The problem persists in Kubuntu 14.04 and LibreOffice 4.2.3.3.

However, now the bug is a bit different. The Save dialog window is not so slow, but it is slow yet. And LibreOffice crashes if you wait enought time in the save dialog window.
Comment 12 Luboš Luňák 2014-04-25 14:35:56 UTC
There shouldn't be any long delays with my recent fix, and with https://bugreports.qt-project.org/browse/QTBUG-38585 there shouldn't be even small delays.