Hi, LO calc UI hangs when using [window->freeze] in one of worksheets. to reproduce: 1. open new calc document 2. open 2 worksheets 3. inside one of worksheets, select any cell (>=b>=2). 4. select [freeze] from [window] menu. 5. now switch to the other worksheet, press ctrl_f to open the [Find...] dialog 6. press esc to cancel the dialog 7. now UI freeze (with high cpu usage) this also happens in my debian 7.7.0 amd64 gnome3 desktop. (but not windows)
On pc Debian x86-64 with LO Debian (testing) package 4.3.3, I don't reproduce this. (I selected B2 in worksheet1) Did you install any LO specific extensions? For the test, could you rename your LO directory profile (see https://wiki.documentfoundation.org/UserProfile#GNU.2FLinux) and give it a new try?
Today I tried many fresh installs of debian and ubuntu with different locales plus fresh installation of lo in virtualbox vms, finally I figured out it was because of the input method called "fcitx" which was installed by default in debian chinese specific version conflicts with lo. I tried closed it off in my freebsd workstation, then the hang problem gone. In ubuntu the default input method for chinese users is ibus, it runs peacefully with lo. So I'm not sure if this conflicts should be resolved by lo developers...
(In reply to m.jackie.plus from comment #2) > Today I tried many fresh installs of debian and ubuntu with different > locales plus fresh installation of lo in virtualbox vms, finally I figured > out it was because of the input method called "fcitx" which was installed by > default in debian chinese specific version conflicts with lo. Thanks for tracking this down! > I tried closed > it off in my freebsd workstation, then the hang problem gone. In ubuntu the > default input method for chinese users is ibus, it runs peacefully with lo. > So I'm not sure if this conflicts should be resolved by lo developers... It sounds like this is something for Debian to address, but I'll ask the expert :-) Rene: Suggestions on whether this issue should be handled in Debian or in LO?
That doesn't make sense. That obscure "Debian chinese version" installs that software. (It's also installed when you choose chinese desktop) And? It's some software other distros might also ship. -> not a Debian bug but a fcitx bug. (Or a LO one where it is badly interacting with it, afaicr there were some things like this with other input methods in the past, too). Not everything which happens because some distro installs package Y is a distro bug.
(In reply to Rene Engelhard from comment #4) > That obscure "Debian chinese version" installs that software. (It's also > installed when you choose chinese desktop) And? It's some software other > distros might also ship. > > -> not a Debian bug but a fcitx bug. (Or a LO one where it is badly > interacting with it, afaicr there were some things like this with other > input methods in the past, too). Looks like the first step is to repro this. Step two is to ask a LibreOffice dev to decide if it's ours or if it should go to fcitx. Julien/Rene: Can either one of you reproduce the bug after installing the Chinese Desktop in Debian? Thanks!
(In reply to Robinson Tryon (qubit) from comment #5) >... > Julien/Rene: Can either one of you reproduce the bug after installing the > Chinese Desktop in Debian? Which one? task-chinese-s-desktop - Simplified Chinese desktop task-chinese-t-desktop - Traditional Chinese desktop Then should I just give a try to the initial description to reproduce the bug or must I change a parameter in my env first?
This is not a critical bug, lowering to major. Reason - clearly not affecting a lot of users (note there are no dupes, no comments outside of QA and a developer). Lastly, moving to NEEDINFO - we need clearer guidelines as to how to reproduce this (assume we're running an English locale, we'll need guides as to how to install that keyboard layout, links/pictures showing what steps to take would be nice (or a video), etc...) Once you provide the necessary stuff we'll try to move it forward. Thanks for your patience and understanding.
I can consistently reproduce this issue using the steps described in the original bug report. I'm running LibreOffice 5.1.3 on Debian 8 Jessie (stable-backports package libreoffice 1:5.1.3-1~bpo8+1), together with fcitx 1:4.2.8.5-2. All x86_64/amd64. The system and user locales have always been US English (en_US.UTF-8). I do not have any of the chinese-desktop packages installed, just some specific packages for Chinese support, such as fcitx. It does not matter which input method is selected in fcitx. The problem even occurs when there is no Chinese input method configured (i.e. only a US English input method configured). In LO, I tried changing the following settings in Options -> Language Settings -> Languages: - Locale setting - Checking or unchecking Default Languages for Documents -> Asian - Selecting different languages in the dropdown next to Default Languages for Documents -> Asian - Checking or unchecking Enhanced Language Support -> Ignore system input language. It all doesn't make a difference. For the bug to occur, fcitx needs to be running before or at step 6 of the steps described in the original bug report. It does not matter if it is running or not in the earlier steps. The only way I can prevent LO from hanging is by not having fcitx running at step 6. Answering the NEEDINFO: Try installing fcitx without any (Chinese) input methods first. Considering the above, that might already be enough to reproduce the issue: $ sudo apt-get install fcitx $ im-config (In im-config, select fcitx.) Perhaps logout and login again. If the fcitx tray icon does not appear, start it manually: $ fcitx Then follow the steps described in the original bug report to reproduce the bug. If this is not enough for reproducing, let me know, so I can provide a full list of installed packages. Changing from NEEDINFO to NEW.
** 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 (5.4.1 or 5.3.6 https://www.libreoffice.org/download/ 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) http://downloadarchive.documentfoundation.org/libreoffice/old/ 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 helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170901
I can still reproduce this on LO 5.4.0.3. Different PC, running Debian Stretch 9.1 (upgraded from Debian Jessie 8) with fcitx. With regard to step 4 of the steps to reproduce, note that Freeze Cells has moved in the menu structure. Step 4 should now read: 4. View -> Freeze Cells -> Freeze Rows and Columns I tried with both GTK+ 2 and GTK+ 3. Application hangs with both.
I also reproduce this issue. I reported a similar bug 112998 (currently in UNCONFIRMED status) which is also related to hang when Fcitx enabled. Maybe You guys can try to reproduce that one.
** 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I can still reproduce this bug in LO 6.1.3.2. Version: 6.1.3.2 Build ID: 1:6.1.3-1~bpo9+2 CPU threads: 2; OS: Linux 4.18; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); Calc: group threaded
I currently cannot reproduce both fcitx-related issues (bug 85795 and bug 112998) either with gtk2 or gtk3 anymore. Version: 6.3.2.2 Build ID: 1:6.3.2-1~bpo10+1 CPU threads: 2; OS: Linux 4.19; UI render: default; VCL: gtk2; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded Version: 6.3.2.2 Build ID: 1:6.3.2-1~bpo10+1 CPU threads: 2; OS: Linux 4.19; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded However, since the last time I could still reproduce at least one of the bugs, I upgraded LibreOffice, fcitx and many other components on my system: LO 6.1.3.2 (*) -> 6.3.2.2 fcitx 4.2.9.1-6 -> 4.2.9.6-5 libgtk2.0-0 2.24.31-2 -> 2.24.32-3 libgtk-3-0 3.22.11-1 -> 3.24.5-1 Debian 9 -> 10 * Bug 112998 last tested and reproduced with 5.4.2.2.0+. Bug 85795 with LO 6.1.3.2. So, while something seems to have been fixed somewhere to make the bug disappear for me, there may still be a problem with LO that let the bug show up before and maybe let it show up again in the future under certain circumstances. For example, if a bug was fixed in fcitx to make this disappear now, LO still should not have hung even if fcitx had a bug, right? Of course, there is no need in keeping a report open for a bug that has become unreproducible, but I cannot assume that just based on my own report. Maybe others can confirm that this has become unreproducible for them as well or someone can point to a specific fix that was made in LO, and then close this bug. I will post this in both bugs 85795 and 112998, as they seem very related. Not sure enough to mark one of them as duplicate, though. Again, maybe someone else can confirm before doing that.
Thanks, let's close
Alright then :) Thanks.