Bug 156263 - Calc windows cannot be closed after focus change from Validity dialog
Summary: Calc windows cannot be closed after focus change from Validity dialog
Status: REOPENED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.2.0.4 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:26.2.0 target:25.8.3 target:25...
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Cell-Validity
  Show dependency treegraph
 
Reported: 2023-07-12 22:59 UTC by Gabor Kelemen (Collabora)
Modified: 2025-10-13 10:29 UTC (History)
20 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 Gabor Kelemen (Collabora) 2023-07-12 22:59:28 UTC
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
Comment 1 ady 2023-07-13 09:11:51 UTC Comment hidden (obsolete)
Comment 2 ady 2023-07-27 02:41:05 UTC
(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.
Comment 3 QA Administrators 2025-07-27 03:09:39 UTC Comment hidden (obsolete)
Comment 4 Ville Aakko 2025-09-06 15:05:13 UTC
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.
Comment 5 Takenori Yasuda 2025-09-06 15:57:23 UTC
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.
Comment 6 Commit Notification 2025-09-18 12:09:48 UTC
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.
Comment 7 Timur 2025-09-18 12:34:23 UTC
*** Bug 166527 has been marked as a duplicate of this bug. ***
Comment 8 Pranam Lashkari 2025-09-19 06:17:37 UTC
*** Bug 168468 has been marked as a duplicate of this bug. ***
Comment 9 Takenori Yasuda 2025-09-20 02:22:22 UTC
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.
Comment 10 Commit Notification 2025-09-30 09:21:05 UTC
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.
Comment 11 Aron Budea 2025-09-30 10:29:22 UTC
*** Bug 167866 has been marked as a duplicate of this bug. ***
Comment 12 Aron Budea 2025-09-30 10:29:31 UTC
*** Bug 168206 has been marked as a duplicate of this bug. ***
Comment 13 Aron Budea 2025-09-30 10:29:38 UTC
*** Bug 168353 has been marked as a duplicate of this bug. ***
Comment 14 Aron Budea 2025-09-30 10:29:45 UTC
*** Bug 168397 has been marked as a duplicate of this bug. ***
Comment 15 Aron Budea 2025-09-30 10:29:58 UTC
*** Bug 168492 has been marked as a duplicate of this bug. ***
Comment 16 Aron Budea 2025-09-30 10:30:12 UTC
*** Bug 168553 has been marked as a duplicate of this bug. ***
Comment 17 Aron Budea 2025-09-30 10:30:26 UTC
*** Bug 168570 has been marked as a duplicate of this bug. ***
Comment 18 Aron Budea 2025-09-30 10:30:34 UTC
*** Bug 168618 has been marked as a duplicate of this bug. ***
Comment 19 Takenori Yasuda 2025-09-30 15:24:31 UTC
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.
Comment 20 Takenori Yasuda 2025-10-01 05:49:29 UTC
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.
Comment 21 Commit Notification 2025-10-01 11:09:31 UTC
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.
Comment 22 Xisco Faulí 2025-10-02 10:30:03 UTC
*** Bug 168658 has been marked as a duplicate of this bug. ***
Comment 23 Georg 2025-10-02 11:28:55 UTC
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.
Comment 24 Xisco Faulí 2025-10-02 14:09:57 UTC
*** Bug 168482 has been marked as a duplicate of this bug. ***
Comment 25 Xisco Faulí 2025-10-02 14:10:13 UTC
*** Bug 168261 has been marked as a duplicate of this bug. ***
Comment 26 m_a_riosv 2025-10-03 22:19:31 UTC
*** Bug 168682 has been marked as a duplicate of this bug. ***
Comment 27 Buovjaga 2025-10-09 18:14:17 UTC
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
Comment 28 Bene-Jázem 2025-10-12 01:13:32 UTC
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)
Comment 29 Takenori Yasuda 2025-10-12 04:02:34 UTC
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.
Comment 30 Buovjaga 2025-10-12 08:03:10 UTC
(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
Comment 31 xordevoreaux 2025-10-13 09:44:29 UTC
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.
Comment 32 xordevoreaux 2025-10-13 09:48:36 UTC
(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
Comment 33 Buovjaga 2025-10-13 10:22:15 UTC
(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.
Comment 34 xordevoreaux 2025-10-13 10:25:51 UTC
(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.
Comment 35 Buovjaga 2025-10-13 10:29:24 UTC
(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.