Description: When LibreOffice is open, if you attempt to tile the window of either the landing page, or while in an office file, it will become unresponsive and need to be force quit. Steps to Reproduce: 1. Open LibreOffice. 2. Hold down the options key and drag the window to a side of the screen to tile it in that portion. 3. Wait a few seconds and the mouse cursor will turn into a spinny ball and the program will become unresponsive. Actual Results: The program became unresponsive, the only option is to force quit the application. Expected Results: The window will tile to a portion of the screen. Reproducible: Always User Profile Reset: Yes Additional Info: If you use your mouse to tile the window using the green stoplight button on the top left of the program by holding down on it and clicking the desired position in the context menu, it will work just fine. Version: 26.2.0.3 (AARCH64) Build ID: afbbd0df0edb6d40b450b0337ac646b0913a760c CPU threads: 10; OS: macOS 26.2; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Confirming with Version: 25.8.4.2 (AARCH64) Build ID: 290daaa01b999472f0c7a3890eb6a550fd74c6df CPU threads: 8; OS: macOS 26.3; UI render: Skia/Metal; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded but I have to have 3 windows open on the desktop space, and then try and move the 3rd window around with the Option key.
Created attachment 205639 [details] Apple Trace on hang
Dan: can you reproduce? I wonder, if it can be bibisected or if it's something related to Tahoe specifically. https://wiki.documentfoundation.org/QA/Bibisect https://wiki.documentfoundation.org/QA/Bibisect/macOS
(In reply to Buovjaga from comment #3) > Dan: can you reproduce? I wonder, if it can be bibisected or if it's > something related to Tahoe specifically. > > https://wiki.documentfoundation.org/QA/Bibisect > https://wiki.documentfoundation.org/QA/Bibisect/macOS I can reproduce with Tahoe on very recent git main, with just two windows. I'll check on Sequoia too. But I don't think it's a recent issue in the LO code, it's probably been lurking for quite a while...
Might be related to bug 128186 ?
(In reply to Alex Thurgood from comment #5) > Might be related to bug 128186 ? I think it is related to my "live resizing" fix for tdf#155092. Although I haven't been able to reproduce this bug on my laptop, I am able to get my local LibreOffice master build to hang if I do the following steps: 1. Open 3 empty Writer documents 2. Press the Option key and then drag the front Writer window to the left or right edge so that the window gets resized to half the screen when the dragged ends 3. Drag the same window's titlebar without the Option key so that the window resizes back to its original size 4. Press Command-w to close the window and LibreOffice hangs I get what appears to be the same sample as in attachment #205639 [details] so I played around with the event handling code and found that the debug patch below stops the hang that I see. Maybe @Dan can see if hanging stops with the debug patch? If the debug patch works in @Dan's build, then my guess is that ImplGetSVData()->mpWinData->mbIsLiveResize is not being reset to "false" after dragging ends for some reason: diff --git a/vcl/osx/salinst.cxx b/vcl/osx/salinst.cxx index 9c0acd6449b1..8604a2619152 100644 --- a/vcl/osx/salinst.cxx +++ b/vcl/osx/salinst.cxx @@ -587,11 +587,13 @@ bool AquaSalInstance::DoYield(bool bWait, bool bHandleAllCurrentEvents) // the front of the event queue so no more events will be // dispatched until live resizing ends. Surprisingly, live // resizing appears to end in the next mouse down event. +#if 0 if ( ImplGetSVData()->mpWinData->mbIsLiveResize && [pEvent type] == NSEventTypeLeftMouseUp ) { [NSApp postEvent: pEvent atStart: YES]; return false; } +#endif [NSApp sendEvent: pEvent]; if ( isWakeupEvent( pEvent ) )
OK. I have uploaded the following patch that fixes the hang I was seeing (see comment #6). @Dan: do you see any change with the following patch? I'm not sure if the hang I am seeing isn't a different bug than this bug: https://gerrit.libreoffice.org/c/core/+/200374
(In reply to Patrick (volunteer) from comment #7) > OK. I have uploaded the following patch that fixes the hang I was seeing > (see comment #6). > > @Dan: do you see any change with the following patch? I'm not sure if the > hang I am seeing isn't a different bug than this bug: > > https://gerrit.libreoffice.org/c/core/+/200374 Must be something else going on; the patch doesn't fix the hang behavior I see (still on 26.2 if that makes a difference) with option-dragging a window.
(In reply to dcbw@libreoffice.org from comment #8) > Must be something else going on; the patch doesn't fix the hang behavior I > see (still on 26.2 if that makes a difference) with option-dragging a window. Hmmm. I wonder what is actually happening when this bug occurs. I still cannot reproduce this bug on my Tahoe 26.3 laptop. But from the sample in attachment #205639 [details], it looks like -[NSApp nextEventMatchingMask:...] is getting called repeatedly so maybe LibreOffice is waiting for a native event that never gets dispatched? There are a handful of -[NSApp postEvent:atStart:] calls in vcl. Maybe one of those calls are preventing some necessary event from getting dispatched?
(In reply to Patrick (volunteer) from comment #9) > There are a handful of -[NSApp postEvent:atStart:] calls in vcl. Maybe one > of those calls are preventing some necessary event from getting dispatched? OK. So my theory behind -[NSApp postEvent:atStart:] is that when "atStart:" is "YES", the native queue gets flooded by LibreOffice posting new events at the front of the queue faster than it can dispatch those same events. So I went through these calls and it appears to me that there is really only one place that posts to the front of the native queue while dragging a window with the Option key to the edge of screeen is in the following debug patch. @Dan: it probably won't change anything, but can you test my debug patch? Worst case is we can ignore native queue flooding and live resizing as causes: diff --git a/vcl/osx/saltimer.cxx b/vcl/osx/saltimer.cxx index 9dc6c6d43f29..05adb46e6029 100644 --- a/vcl/osx/saltimer.cxx +++ b/vcl/osx/saltimer.cxx @@ -153,7 +153,7 @@ void AquaSalTimer::handleTimerElapsed() callTimerCallback(); } else - queueDispatchTimerEvent( true ); + queueDispatchTimerEvent( false ); } bool AquaSalTimer::handleDispatchTimerEvent( NSEvent *pEvent )
Created attachment 205855 [details] Instruments screen snapshot of LibreOffice hang I finally was able to reproduce this bug! I cannot reproduce it consistently, but it is most likely to occur when I have the Instruments application running a Time Profile on LibreOffice while I am Option-dragging a window in LibreOffice. Fortunately, I was able to capture a screen snapshot of the Time Profile before having to kill everything. What I see in the heaviest stack trace is LibreOffice is spending a lot of time in _LSCopyFrontApplication() while in a native NSTimer or CFRunLoopSource. So next step is to put some debug code in to see what copy and paste operations are happening while the hang occurs.
(In reply to Patrick (volunteer) from comment #11) > What I see in the heaviest stack trace is LibreOffice is spending a lot of > time in _LSCopyFrontApplication() while in a native NSTimer or > CFRunLoopSource. So next step is to put some debug code in to see what copy > and paste operations are happening while the hang occurs. Didn't see any copy or paste calls in vcl/osx/clipboard.cxx while Option-dragging a window either before or during a hang. So that's not triggering the _LSCopyFrontApplication() calls. I was looking at the copy and paste code because _LSCopyFrontApplication() is called by something I am pretty sure that LibreOffice does not call directly: _NS_SetBasicPasteTelemetry(). I disabled all options in "Analytics & Improvements" in the Settings application, but LibreOffice is still spending a lot of time in _LSCopyFrontApplication() so that doesn't seem to affect the bug either. :(
So odd; I can reliably reproduce on 26.2 (can't upgrade yet cause I gotta clear space on this 256GB machine). It definitely seems timing related; after adding a bunch of debug printfs I can trigger with the first window; previously it would take a couple. I have 'Related: tdf#155092 don't rely on cached "in live resize" value' applied BTW. Anyway, it *looks* like we're getting stuck in DoYield() and repeatedly dequeuing the same two events over and over after we start live-resize: ###### DoYield: event 0x8b8ff5740 NSEvent: type=LMouseUp loc=(398.516,727.176) time=499443.1 flags=0x80020 win=0x8b359cc80 winNum=41501 ctxt=0x0 evNum=19185 click=0 buttonNumber=0 pressure=0 deviceID:0x200000000000029 subtype=NSEventSubtypeTouch ###### DoYield: event 0x8b8ff5680 NSEvent: type=LMouseUp loc=(398.516,727.176) time=499443.1 flags=0x80020 win=0x8b359cc80 winNum=41501 ctxt=0x0 evNum=19185 click=0 buttonNumber=0 pressure=0 deviceID:0x200000000000029 subtype=NSEventSubtypeTouch [aside: I'm printing pEvent with %p and [pEvent description] here and only ever get these two pEvent pointer values out of it... always same [description] but pointer values switch off] This seems to verify your theory that we're flooding the queue. In the bad case, when we hang, I never see [windowDidEndLiveResize] get called. Setting queueDispatchTimerEvent( false ); doesn't change anything for me.
Anyway, to be clearer: I never see [windowDidEndLiveResize] get called so we never end live resize and never clear the MouseUp events at the head of the queue that we keep reposting. What's also odd is that in the "good" case I never see any LMouseUp events, either before or after we start pumping the queue.
(In reply to dcbw@libreoffice.org from comment #14) > Anyway, to be clearer: I never see [windowDidEndLiveResize] get called so we > never end live resize and never clear the MouseUp events at the head of the > queue that we keep reposting. > > What's also odd is that in the "good" case I never see any LMouseUp events, > either before or after we start pumping the queue. I added a CFShow(pEvent) for every event right before my fix for tdf#155092 and I can reproduce this bug much easier. Does commenting out the entire tdf#155092 block of code stop the hanging for you? In the meantime, I will try and implement a replacement fix for tdf#155092 that doesn't need to repost LMouseUp events.
(In reply to Patrick (volunteer) from comment #15) > In the meantime, I will try and implement a replacement fix for tdf#155092 > that doesn't need to repost LMouseUp events. I've uploaded a replacement fix for tdf#155092 in the following patch: https://gerrit.libreoffice.org/c/core/+/200870 @Dan: does the patch have any effect on this bug?
Having this issue too. Just dragging a LO window to either side of the screen (to activate tiling) and letting go results in a endless hang. Only solution is to force quit.
*** Bug 171134 has been marked as a duplicate of this bug. ***
Update: my patch in comment #16 caused tdf#155092 to reoccur so I've abandoned that patch. One positive piece of data was that @Dan couldn't reproduce this bug with the patch so that confirms that my original fix for tdf#155092 is the cause of this bug. So, after some debugging, I have uploaded the following patch that I am hoping fixes this bug without causing tdf#155092: https://bugs.documentfoundation.org/show_bug.cgi?id=170740 @Dan: Does the patch fix this bug on your machine? I can no longer reproduce this bug but it has been difficult for me to reproduce it without this patch.
(In reply to Patrick (volunteer) from comment #19) > https://bugs.documentfoundation.org/show_bug.cgi?id=170740 Oops. Wrong link. Here is the link to the patch in comment #19: https://gerrit.libreoffice.org/c/core/+/200957
(In reply to Patrick (volunteer) from comment #20) > (In reply to Patrick (volunteer) from comment #19) > > https://bugs.documentfoundation.org/show_bug.cgi?id=170740 > > Oops. Wrong link. Here is the link to the patch in comment #19: > > https://gerrit.libreoffice.org/c/core/+/200957 I think the patch is just doing pointer comparison on the NSEvents? In my case there are two NSEvent pointers getting alternately returned, though they both contain exactly the same data. So I did this: static bool sameNSEvent( NSEvent *pFirst, NSEvent *pSecond ) { return ([pFirst type] == NSEventTypeLeftMouseUp && [pSecond type] == NSEventTypeLeftMouseUp && [pFirst modifierFlags] == [pSecond modifierFlags] && [pFirst timestamp] == [pSecond timestamp] && [pFirst window] == [pSecond window] && [pFirst windowNumber] == [pSecond windowNumber] && [pFirst clickCount] == [pSecond clickCount] && [pFirst buttonNumber] == [pSecond buttonNumber] && [pFirst eventNumber] == [pSecond eventNumber] && [pFirst pressure] == [pSecond pressure] && NSEqualPoints([pFirst locationInWindow], [pSecond locationInWindow])); } But even then there's some oddity with window live resize after snapping; I'll try to characterize it better tomorrow (Friday).
(In reply to dcbw@libreoffice.org from comment #21) > I think the patch is just doing pointer comparison on the NSEvents? In my > case there are two NSEvent pointers getting alternately returned, though > they both contain exactly the same data. So I did this: Interesting. I am only seeing one left mouse up events when live resizing via the bottom right corner of the window and none when Option-dragging a window. I do agree that pointer comparison isn't going to work as I found that reposting an event and then immediately fetching it from the native event queue returns a different pointer so like NSApp makes a copy of the event somewhere. What happens if you replace the following line in my patch: if ( bRepost ) with the following?: if ( pLastRepostedEvent ) I will take another look at what is occurring in tdf#155092, but what the repost code is trying to do is to stop recursive event dispatching until the current event that made the recursive call is finished dispatching. Basically, this gives the LibreOffice internal resizing and repainting timers a chance to catch up with the native window's size changes before dispatching the left mouse up and any events after it.
(In reply to Patrick (volunteer) from comment #22) > What happens if you replace the following line in my patch: Ignore my changes in comment #22 as it won't work. Try the following debug patch instead: diff --git a/vcl/osx/salinst.cxx b/vcl/osx/salinst.cxx index 669df792606c..a5b42724adf0 100644 --- a/vcl/osx/salinst.cxx +++ b/vcl/osx/salinst.cxx @@ -600,11 +600,12 @@ bool AquaSalInstance::DoYield(bool bWait, bool bHandleAllCurrentEvents) // prevent tdf#155092 during normal live resizing so allow // last mouse up events to be reposted but only once. static NSEvent *pLastRepostedEvent = nil; - bool bRepost = ( pLastRepostedEvent != pEvent ); + bool bRepost = true; if ( pLastRepostedEvent ) { [pLastRepostedEvent release]; pLastRepostedEvent = nil; + bRepost = false; } if ( bRepost ) {
OK. My patch in comment #20 really is slop and had a couple of ways it could get messed up so I rewrote some of the patch to evaluate every single event. Hopefully this should work better than the last patch: https://gerrit.libreoffice.org/c/core/+/200957 @Dan: no need to try my debug patches. Patchset 4 in the above patch should avoid any pointer comparison and hopefully avoid accidental reordering of events.
@Patrick: latest patch (#5 I think) works well for me on 26.3.1; couldn't reproduce the issues I was seeing earlier. I can test on 26.2 as well if you think that would be useful, which is what I tested all previous iterations on. I don't quite trust the OS to do the same thing between versions. What do you think?
@Patrick: patch 5 tested good on 26.2 as well.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7575bbe54a6afec3b289985593977579835cce3f tdf#170740 only repost the same left mouse up event once It will be available in 26.8.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.
(In reply to dcbw@libreoffice.org from comment #26) > @Patrick: patch 5 tested good on 26.2 as well. Thank you for testing the patch! I have committed the patch. Can anyone else confirm that my patch fixes this bug? The fix should be in tomorrow's (08 March 2026) nightly master builds: https://dev-builds.libreoffice.org/daily/master/current.html Note for macOS testers: the nightly master build installer does not overwrite any LibreOffice official versions. Instead, it will be installed as a separate application called "LibreOfficeDev" in the /Applications folder. Because this is a "test" build, you will need to do the following steps after installing the LibreOfficeDev application: 1. Go to the Finder and navigate to the /Applications/Utilities folder 2. Launch the "Terminal" application 3. Paste the following command in the Terminal application window and press the Return key to execute the command: xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app 4. Launch LibreOfficeDev
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-26-2": https://git.libreoffice.org/core/commit/d655a441b66aac6e20776b41d05178593c6c991b tdf#170740 only repost the same left mouse up event once It will be available in 26.2.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.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-25-8": https://git.libreoffice.org/core/commit/09749f3b3887eaf7ef108c9cb38238b31224b6a6 tdf#170740 only repost the same left mouse up event once It will be available in 25.8.7. 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.
Hello, Patrick. I downloaded version 25.8.7, tested it, and it works without errors. Thank you for such a quick reaction and implementation - well done. This was my first experience in posting a bug on this resource. I just learned how to write a review. Sincerely, Denis.
*** Bug 171210 has been marked as a duplicate of this bug. ***
*** Bug 170687 has been marked as a duplicate of this bug. ***
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-25-8-6": https://git.libreoffice.org/core/commit/bc430d22bcb13bbba72bb30eec6d105260203557 tdf#170740 only repost the same left mouse up event once It will be available in 25.8.6. 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.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-26-2-2": https://git.libreoffice.org/core/commit/4da0a8fd2b09344eade174319951ba863322c1d0 tdf#170740 only repost the same left mouse up event once It will be available in 26.2.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 171195 has been marked as a duplicate of this bug. ***
*** Bug 171465 has been marked as a duplicate of this bug. ***
*** Bug 171588 has been marked as a duplicate of this bug. ***
*** Bug 170673 has been marked as a duplicate of this bug. ***