Have a document open in libreoffice
Open a new text document
Type something in it, e.g., "test"
Open the Save dialog, give the document a name, e.g., "test.doc", and *select and copy that text into the memory* (ctrl+c or select with mouse)
After clicking "Save", a long lag occurs and libreoffice greys out
The above lag does not happen if no text in the save dialog is selected
Which desktop environment, please? Gnome? KDE3? KDE4?
Gnome, Fedora 14, 126.96.36.199-83.fc14.i686
I now noticed that LibreOffice stays sluggish after doing the "trick" reported here. It greys out for some seconds after for example entering text or using the cursor. A close and restart of LibreOffice turns the behaviour back to normal.
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
needinfo keyword redundant by needinfo status.
Dear bug submitter!
Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.
To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement
Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.
something comparable still happens with libreoffice 188.8.131.52 (on up-to-date fedora 17 using kde):
open a new document, write something in it
save, highlight and copy the suggested file name (e.g., "Untitled 1")
click on 'save' and it will take seconds before anything happens
I have did five different tests to reproduce the from this report. Without success.
Test-OS: Opensuse 12.1 32bit, KDE, LO 184.108.40.206: could not reproduce, LO works fine;
Test-OS: Opensuse 12.2 RC1 32bit, KDE, LO 220.127.116.11: could not reproduce, LO works fine;
Test-OS: LinuxMint 12 64bit, Gnome, LO 18.104.22.168: could not reproduce, LO works fine;
Test-OS: Windows 7 64bit, LO 22.214.171.124: could not reproduce, LO works fine;
Test-OS: Ubuntu 12.04 32bit, Gnome, LO 126.96.36.199: could not reproduce, LO works fine;
your suspicion of a bug does not seem to be confirmed.
What is your opinion: bug or something else?
If bug: describe your procedure exactly
Did not we have this problem a few days ago at another bug? Which bug (duplicate)?
I have tested one more time.
Test-OS: Fedora17 32bit, Gnome, LO 188.8.131.52: could not reproduce, LO works fine
Thanks for testing this. I can still reproduce it on a 64bit fully up-to-date Fedora 17 machine, using KDE and LibreOffice 184.108.40.206 (Build ID: 350m1(Build:2)). Exact steps to reproduce it (please tell me if you need more detail):
1) quit libreoffice
2) in terminal, make sure libreoffice is not running ('ps aux | grep offi')
3) open libreoffice in terminal (typing 'soffice'). After flash screen,
the 'welcome' screen appears, select Text Document.
4) type 'hello', then save (ctrl+s)
5) in the 'Save' window, highlight the default file name using the mouse, and copy it (ctrl+c)
6) click on the 'save' button. A delay of several seconds occurs.
Nothing is reported within the terminal, by the way. And if I don't highlight the text in step 5, or only highlight it without subsequent copying, no such delay occurs.
If I'm really the only one having/reporting this minor problem, no worries, I can live with it.
Justone thing to test:
rename user dir
Start LibO and ch eck wether this problem stil exists...
Thank you suggesting this, Florian
renamed .config/libreoffice/3/user/ to .config/libreoffice/3/user1/,
opened libreoffice and did the same process as before; same problem happens
a) Still with 3.6? 3.5 lifecicle is terminated
b) really only with writer?
c) also with .odt? I wonder why you used .doc in your explications.
d) Do you observe this problem with other (not LibO) applications?
e) LibO dialog or OS dialog?
I just was going to decide to give up when I reproduced it with LibO 220.127.116.11 on Ubuntu 12.04x64 (on VirtualBox). Because I am WIN user I have a very basic test environment.
Steps how I reproduced (preparations):
1. Launch LibO from 'Applications -> Office'
2. Open writer from LibO Start Center
3. Menu 'Tools -> Options -> LibO -> General - open/save dialogs', uncheck
"Use LibO" <ok>
4. Type "hello"
5. Menu 'File -> Save'
> Ubuntu FILESAVE dialog appears, Document name "Untitled 1" highlighted in
File Name pane, wants to save my new document in "Documents" folder, what
already contains "Untitled 1" (does not matter, but you can check and delete
in a step 0)
6. <Control+c> for "copy"
7. Click <Save> button
Expected: Save immediately or ask "overwrite"
Actual: > 10s delay after click on button
That behavior was 100% reproducible for me, but not with LibO files dialog, where the problem is not reproducible at all.
Also reproducible If I replace "Untitled 1" by a new name ("abc"), <control+a> to select name, <control+c> for Copy.
Also reproducible with LibO 18.104.22.168 on Ubuntu 11 32 bit
I can confirm that this still happens when saving as .doc (I live in an imperfect world where people expect .doc, not .odt) with the most recent version. Long delay after pressing 'save' if name highlighted beforehand. Not much happens, no high cpu, just a long lag.
As reported by Rainer, the lag does not happen when using .odt.
LibreOffice 22.214.171.124-8.fc18, 64b, KDE
LuboÅ¡ LuÅak committed a patch related to this issue.
It has been pushed to "master":
work around LO blocking when asking for QClipboard's contents, helps fdo#35950
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:
Affected users are encouraged to test the fix and report feedback.
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.3 or later)
If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)
2. Test your bug
3. Leave a comment with your results;
4a. If the bug was present with 3.3 - set version to "inherited from OOo";
4b. If the bug was not present in 3.3 - add "regression" to keyword
Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa
Thank you for your help!
-- The LibreOffice QA Team This NEW Message was generated on: 2015-06-08
works for me, version 126.96.36.199