This is split off from bug 155708 comment #1 STR_B, obtaining a much worse resulting behavior: 0. LO is closed before starting the procedure. Open Start Center. 1. Open only one new (empty) Calc window (Untitled 1). 2. [CTRL]+[N] (Untitled 2) 3. Menu Data > Validity 4. Change window to "Untitled 1" (on MS Windows, [ALT]+[TAB]). 5. Change window to "Untitled 2" (on MS Windows, [ALT]+[TAB]). 6. Click on "All values" of the "Allow" field. 7. Click on "Cell range" of the "Allow" field. 8. Click once inside the "Source" field. 7. Change window to "Untitled 1" (on MS Windows, [ALT]+[TAB]). 9. Change window to "Untitled 2" (on MS Windows, [ALT]+[TAB]). Intermediate results: The Validity dialog is still displayed. 10. [ESC] to exit the dialog. 11. Menu File > Close (the window is still opened). 12. Open a new (empty) Writer window; it can be successfully closed. 13. Open a new (empty) Calc window; it cannot be closed. Actual results: Calc windows can _not_ be actually closed; they have to be forcefully closed by using Task Manager. When re-opening LO, these will be listed for recovery attempt. Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: fcbae818b793a9ee97a1b5ddc53902be7a2376f5 CPU threads: 15; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: de-DE (hu_HU); UI: en-US Calc: threaded This seems to have started in 7.2 with: https://git.libreoffice.org/core/+/618cb39b558b7e3f9a6f2aa8cf0a935602118388 author Caolán McNamara <caolanm@redhat.com> Sat Mar 27 16:20:43 2021 +0000 committer Caolán McNamara <caolanm@redhat.com> Sat Mar 27 20:10:49 2021 +0100 tdf#141141 sync SalFrame::GetFrameWeld and weld::GetPopupParent Before this both windows could be closed just fine. Adding CC to: Caolán McNamara
Since this is a split off from bug 155708, let's CC Balazs Varga too. Shouldn't the "Component" field of this bug 156263 be "Calc" instead of "UI"?
(In reply to ady from comment #1) > Since this is a split off from bug 155708, let's CC Balazs Varga too. > > Shouldn't the "Component" field of this bug 156263 be "Calc" instead of "UI"? I'm changing the component field from UI to Calc.
Dear Gabor Kelemen (allotropia), 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Hi, This is still an issue on: Version: 25.8.1.1 (X86_64) / LibreOffice Community Build ID: 580(Build:1) CPU threads: 32; OS: Linux 6.16; UI render: default; VCL: kf6 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US 25.8.1-1 Calc: threaded I have to note the UI is broken in various ways in addition to those listed by OP. One can not choose a different table on an open document (CTRL+PgUp and PgDown still work). It's as if the validity dialog, which has been closed, still has focus and is "hijacking" input logic of LO (if this description makes sense). Also, the cell range field is useless, one can not actually choose any cell range. The Validity dialog seems quite broken overall.
Cannot reproduce in the following versions. It closes normally at Step 11. Version: 24.8.7.2 (x86) / LibreOffice Community Build ID: e07d0a63a46349d29051da79b1fde8160bab2a89 CPU threads: 8; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: CL threaded Version: 25.2.6.2 (X86_64) / LibreOffice Community Build ID: 729c5bfe710f5eb71ed3bbde9e06a6065e9c6c5d CPU threads: 8; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: CL threaded Jumbo I believe what is occurring in the LibreOffice 25.8 series is Bug 166527.
Pranam Lashkari committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ef7151c271d14f623759f87d30e452f2e6d66664 tdf#156263: fixes freeze after opening data validity dialog It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 166527 has been marked as a duplicate of this bug. ***
*** Bug 168468 has been marked as a duplicate of this bug. ***
I confirmed that this bug does not occur in the nightly build after applying the patch. Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9ee57c6ac279cf3ea25f1598de6deab6e2d6735a CPU threads: 8; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: CL threaded Jumbo I have a question: could this fix be considered for backport to the LibreOffice 25.8 series? Since the series still has a long time until its end of life and there is a practical impact, as seen in Bug 166527 Comment 17. I believe there is merit in backporting it.
Pranam Lashkari committed a patch related to this issue. It has been pushed to "libreoffice-25-8": https://git.libreoffice.org/core/commit/7e9ef9557da52b219e2c7ce500345510f9cbbc9c tdf#156263: fixes freeze after opening data validity dialog It will be available in 25.8.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 167866 has been marked as a duplicate of this bug. ***
*** Bug 168206 has been marked as a duplicate of this bug. ***
*** Bug 168353 has been marked as a duplicate of this bug. ***
*** Bug 168397 has been marked as a duplicate of this bug. ***
*** Bug 168492 has been marked as a duplicate of this bug. ***
*** Bug 168553 has been marked as a duplicate of this bug. ***
*** Bug 168570 has been marked as a duplicate of this bug. ***
*** Bug 168618 has been marked as a duplicate of this bug. ***
I noticed that this bug has been marked as a duplicate of Bug 166527, but I would like to question whether that is truly the case. According to the reports so far, this issue started in version 7.2, was first reported in 24.2.0 (cf. Comment 0), and is said to still occur in 25.8.1 (cf. Comment 4). However, based on my testing, it does not reproduce in 24.8.7 or 25.2.6 (cf. Comment 5). It seems that the issue stopped occurring between 24.2.0 and 24.8.7. I was able to reproduce this bug in 7.5.9, but neither this bug nor Bug 166527 reproduces when following the steps described in Bug 166527. If these two bugs were indeed duplicates, I believe the same steps should trigger both. In addition, the root-cause commits, affected files, and code locations differ between the two bugs. Given these findings, I believe treating them as duplicates may not be appropriate.
I performed additional testing. Bug 156263 reproduces when multiple Calc documents (either new or existing) are open and steps 3–8 in Comment 0 are executed. If it were truly a duplicate of Bug 166527, then step 8 alone — being the minimal trigger condition — should be sufficient to reproduce the same result with only one Calc document open. However, that did not reproduce the issue. Therefore, it appears that the steps and results of Bug 156263 are specific to that report, while those of Bug 166527 are unique to it. Based on this, it seems more accurate that the issue marked as a duplicate of Bug 156263 should instead be a duplicate of Bug 166527. Tested with: Version: 7.5.9.2 (x86) / LibreOffice Community Build ID: cdeefe45c17511d326101eed8008ac4092f278a9 CPU threads: 8; OS: Windows 10.0 Build 26100; UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: CL threaded I hope this clarification helps refine the relationship between the two reports.
Pranam Lashkari committed a patch related to this issue. It has been pushed to "libreoffice-25-8-2": https://git.libreoffice.org/core/commit/dbb9e475480d446046953b407acc94e2a071c154 tdf#156263: fixes freeze after opening data validity dialog It will be available in 25.8.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 168658 has been marked as a duplicate of this bug. ***
Wow, I'm flashed :) Just tried 25.8.3.0.0 and it worked! Great and fast work. Thank you very much for the quick, competent, and perfect solution. Georg From my side 156263 could be closed.
*** Bug 168482 has been marked as a duplicate of this bug. ***
*** Bug 168261 has been marked as a duplicate of this bug. ***
*** Bug 168682 has been marked as a duplicate of this bug. ***
Not fixed, please everybody focus on the steps in comment 0. Takenori-san was right. Unduplicating from bug 166527. Arch Linux 64-bit Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d0e936765b1b68d614271642629df6c615c7e9ae CPU threads: 8; OS: Linux 6.17; UI render: default; VCL: gtk3 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded Built on 8 October 2025
I've noticed I can't even: input new cells on formulas using mouse or keyboard arrow keys; I can't navigate through sheets unless I use shortcut keys (click at sheet tab doesn't work)
About all bugs (※) marked as duplicates of this one: In my assessment, as stated in comment 20, they are, in fact, duplicates of Bug 166527. In the same version as comment 20 (the version where Bug 156263 occurs), I attempted to reproduce the bug again following each report's steps, but none of them could be reproduced. ※ Bug 167866, Bug 168206, Bug 168353, Bug 168397, Bug 168468, Bug 168482, Bug 168492, Bug 168553, Bug 168570, Bug 168618, Bug 168658, and Bug 168682 (as of 2025-10-12). About this bug: This bug itself ceased to reproduce somewhere between LO 24.2.3 and LO 24.8.2 (※). I don’t know the reason. ※ Although comment 19 stated it was between LO 24.2.0 and LO 24.8.7, subsequent investigation using portable versions allowed us to narrow it down to this range. I would appreciate it if you could also reverify these.
(In reply to Takenori Yasuda from comment #29) > ※ Bug 167866, Bug 168206, Bug 168353, Bug 168397, Bug 168468, Bug 168482, > Bug 168492, Bug 168553, Bug 168570, Bug 168618, Bug 168658, and Bug 168682 > (as of 2025-10-12). I corrected the duplication of these in "ninja mode", without email notifications. > About this bug: > This bug itself ceased to reproduce somewhere between LO 24.2.3 and LO > 24.8.2 (※). I don’t know the reason. I bibisected the fix with linux-64-24.8. Caolán: your commit 294e206ff0651d7081ac96d6c5dfc964728d86f5 fixed it. Resolves: tdf#160509 use BorderWindow client for dialog parent
Using just a single window (not alt-tabbing between two windows), I am not experiencing the bug in my windows environment, which is different than the windows environment listed in comment (0): Version: 25.8.2.2 (X86_64) Build ID: d401f2107ccab8f924a8e2df40f573aab7605b6f CPU threads: 24; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded new LO Calc doc picked a few cells and typed garbage in them grabbed the range to see what the range was went to data validity in an empty cell picked cell range entered the cell range where I'd entered stuff closed the dialog closed the document closed LO No hiccups. Repeated the above using a named range as opposed to a cell range, again, no hiccups. Could close the dialog, save the document, close the document, close LO. I have two monitors, so I don't need to alt+tab. I have two untitled Calc Windows up. Flipping from spread to spread leaves the validity dialog up in the window in which I triggered it, but in following steps 6 - 13 in comment (0), I experience no hiccups. Everything closes and LO quits as expected. Tested it twice, no problems.
(In reply to Bene-Jázem from comment #28) > I've noticed I can't even: input new cells on formulas using mouse or > keyboard arrow keys; I can't navigate through sheets unless I use shortcut > keys (click at sheet tab doesn't work) Not experiencing this at all in Version: 25.8.2.2 (X86_64) Build ID: d401f2107ccab8f924a8e2df40f573aab7605b6f CPU threads: 24; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
(In reply to xordevoreaux from comment #31) > Using just a single window (not alt-tabbing between two windows), I am not > experiencing the bug in my windows environment, which is different than the > windows environment listed in comment (0): Indeed, actually the problem is currently limited only to Linux and gtk3. Windows, gen and kf6 work fine.
(In reply to Buovjaga from comment #33) > (In reply to xordevoreaux from comment #31) > > Using just a single window (not alt-tabbing between two windows), I am not > > experiencing the bug in my windows environment, which is different than the > > windows environment listed in comment (0): > > Indeed, actually the problem is currently limited only to Linux and gtk3. > Windows, gen and kf6 work fine. Ah, ok. I tested because Hardware on the bug is listed as All not Linux so I figured it was including Windows.
(In reply to xordevoreaux from comment #34) > (In reply to Buovjaga from comment #33) > > (In reply to xordevoreaux from comment #31) > > > Using just a single window (not alt-tabbing between two windows), I am not > > > experiencing the bug in my windows environment, which is different than the > > > windows environment listed in comment (0): > > > > Indeed, actually the problem is currently limited only to Linux and gtk3. > > Windows, gen and kf6 work fine. > > Ah, ok. I tested because Hardware on the bug is listed as All not Linux so I > figured it was including Windows. It did, but not anymore apparently.