Steps to Reproduce: 1. Create a simple sheet with the following content in column A: test 1 12 2. Set auto-filter on this column. Then select cell A2 and then click the "Freeze Rows and Columns" toolbar icon. 3. In the drop-down list of the auto-filter, type in "1" in the "Search Item" text box (in order to filter-out the items containing char 1.) Current Behaviour: Calc freezes (not responding) at step 3. Further Information: It seems that the bug only exists if the column contains items which have identical chars. In my example above, the item "1" and "12" both contain the char "1". It is also noted that, in order to reproduce, "Freeze Rows and Columns" must be set. Version: 5.3.6.1 Build ID: 5.3.6.1-6.fc26 OS: Fedora 26 x64. P.S. I am using the LibreOffice version shipped by Fedora. I am not able to test this with the official libreoffice build offered by TDF because of bug 112252.
Can not reproduce Version: 5.3.1.2 Build ID: e80a0e0fd1875e1696614d24c32df0f95f03deb2 CPU Threads: 8; OS Version: Linux 4.9; UI Render: default; VCL: kde4; Layout Engine: new; Locale: nl-BE (en_US.UTF-8); Calc: group Version: 5.3.8.0.0+ Build ID: a0fae00a2d52960eebbb14f08d2de251e0a8ff3f CPU Threads: 8; OS Version: Linux 4.9; UI Render: default; VCL: kde4; Layout Engine: new; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:libreoffice-5-3, Time: 2017-10-05_05:58:12 Locale: nl-BE (en_US.UTF-8); Calc: group Version: 5.4.3.0.0+ Build ID: cc70f137cd853bc22281edb94f15ebe48da871e7 CPU threads: 8; OS: Linux 4.9; UI render: default; VCL: kde4; Locale: nl-BE (en_US.UTF-8); Calc: group
Sorry spoke to soon. Observation is correct but its not freezing and is responding when inserting the number 1 (step 3), comment 1 is based on four numbers in the drop-down list Best regards
I can not confirm with Version: 6.0.0.0.alpha0+ Build ID: 9127d1a89cbfba89eb9df6755ea7b9e161cfc67a CPU threads: 4; OS: Windows 6.1; UI render: default;
Sorry my bad - you need to click "OK" after you type in 1 in the search box.
I'd rather close this as NOTOURBUG. I installed LibreOffice 5.4.2 and tested, the bug does not exist. Thus the bug may be because of the build of Fedora 26. P.S In order to make the TDF build of LibreOffice run in Fedora 26, you need to manually install the "clang" package, as discussed in bug 112252.
Created attachment 136917 [details] Test ODS File Reopened and set to UNCONFIRMED, as I reproduce this in my own build on master. Steps to Reproduce: 1. In the autofilter dropdown of column A, type in 1 in the search box and click OK. --> Calc freezes. Version: 6.0.0.0.alpha0+ Build ID: fbfe55e58c4b14f86cbb2c7b822f727e5b2e4a66 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: zh-CN (zh_CN.UTF-8); Calc: group My autogen.input is as following: --without-help --without-java --without-myspell-dicts --disable-online-update --with-lang=zh-CN zh-TW --with-vendor="Kevin Suo" (all other build options are using defaults)
Exiting the input method "Fcitx" will fix the issue. So there may be some conflicts between LibreOffice and Fcitx.
Sorry, I cannot reproduce this (#112998) with gtk2 or gtk3 on Debian. Version: 5.4.1.2.0+ Build ID: 1:5.4.1-1~bpo9+1 CPU threads: 2; OS: Linux 4.9; UI render: default; VCL: gtk2; Locale: en-US (en_US.UTF-8); Calc: group Version: 5.4.1.2.0+ Build ID: 1:5.4.1-1~bpo9+1 CPU threads: 2; OS: Linux 4.9; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); Calc: group (I can still reproduce #85795 with both gtk2 and gtk3.)
fcitx was running, by the way.
(In reply to Kevin Suo from comment #7) > Exiting the input method "Fcitx" will fix the issue. > So there may be some conflicts between LibreOffice and Fcitx. Hiunn-hué: can you repro with Fcitx?
I cannot reproduce it with ... Version: 5.4.2.2 Build ID: 1:5.4.2~rc2-0ubuntu0.16.04.1~lo2 CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk2; Locale: zh-TW (zh_TW.UTF-8); Calc: group and fcitx 1:4.2.9.1-1ubuntu1.16.04.2+elementary2~ubuntu0.4.1 fcitx-chewing 0.2.2-1 -- Note: I am not using fcitx and therefore not familiar with it, but I still install and enable it to do the test. During the test I could input Chinese with fcitx, so fcitx should be working properly, and the Calc didn't freeze after I finished the steps.
(In reply to Hiunn-hué from comment #11) In Fedora 26, to install fcitx and reproduce this, do: 1. # dnf install fcitx fcitx-pinyin 2. # exit 3. $ imsettings-switch fcitx (a message tray will display on the left-bottom of desktop showing fcitx icon.) 4. Click the input source displayed in ibus icon (right-top of the desktop area) as "en" keyboard (i.e., all input methods used by ibus are disabled) 5. You DO NOT need to set the input method as pinyin in fcitx message tray. 6. Reproduce the bug: in calc: A1: a A2: 1 A3: 11 set autofilter put cursor in A2 and freeze first row type in "1" in the search box of the autofilter dropdown and click OK. calc hangs I am trying my best to get a backtrace. But this may take some time.
Created attachment 137587 [details] gdbtrace.log Calc is not crashing - it hangs when you do the filter. To get the backtrace I used CTRL+C.
An issue is also reported to fcitx issue list: https://github.com/fcitx/fcitx/issues/377
Hi I'm a fcitx developer. So to reproduce this problem the ooo desktop plugin need to be Gtk. Qt(KDE) doesn't have such problem. IBus and Fcitx have been using such implementation for long time: https://github.com/fcitx/fcitx/blob/master/src/frontend/gtk2/fcitximcontext.c#L922 https://github.com/ibus/ibus/blob/master/client/gtk2/ibusimcontext.c#L944 And IMHO it is the only way to get the surrounding text in Gtk "on-time". Otherwise, if the surrounding text is not updated before the key event, the input method won't be able to use the up-to-date surrounding text information to process the key event. I noticed that when after bug is triggered, in spite of the freeze, the memory is increasing dramatically. My guess is that certain function in libreoffice is not reentrant and causes this bug. My trick on reproducing this bug, is to do a "alt-tab" when the drop down list is opened. I can always reproduce this freeze with this additional step. I tried to apply some workaround locally, e.g. delay "retrieve-surrounding" signal and emit it later. The issue is gone here. But I don't know if it can be still triggered in some other places. E.g. , we can't delay the retrieve-surrounding signal when handle key event.
Set to NEW per comment 15.
With suggestions of Xuetian Weng in comment #15, I can now also reproduce. Version: 5.4.2.2.0+ Build ID: 1:5.4.2-3~bpo9+1 CPU threads: 2; OS: Linux 4.9; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); Calc: group
Still reproducible in Version: 6.0.6.2 Build ID：0c292870b25a325b5ed35f6b45599d2ea4458e77 CPU 线程：4; 操作系统：Linux 4.15; UI 渲染：默认; VCL: gtk2; 区域语言：zh-CN (zh_CN.UTF-8); Calc: group
Sorry, comment #18 is a wrong post. Please ignore. P.s. It would be great if we can delete our own message in bugzilla in case of wrong post.
Dear Kevin Suo, 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 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