Description: If LibreOffice shows the Document Recovery dialog when it starts, while the dialog is shown the code in Dialog::Execute() keeps looping in the while ( !xWindow->IsDisposed() && mbInExecute ) loop, calling Application::Yield() again and again endlessly, even if the user doesn't touch anything, move the mouse etc. Steps to Reproduce: Add some debugging output into Dialog::Execute() in vcl/source/window/dialog.cxx and rebuild vcl: while ( !xWindow->IsDisposed() && mbInExecute ) { SAL_DEBUG("Dialog::Execute: Calling Application::Yield()"); Application::Yield(); } Run instdir/LibreOfficeDev.app/Contents/MacOS/soffice. (The started LibreOffice will not get focus, that is another issue, and not serious, as end-users of course aren't supposed to start LibreOffice from the Terminal by explicitly running the soffice binary.) Hit Cmd-N to open a fresh Writer document, type a few words, switch back to the Terminal and kill soffice with Control-C. Run soffice again. You will see an endless loop of debug:1991:499247: Dialog::Execute: Calling Application::Yield() even before you switch focus to the recovery window, and while it has focus. (If you switch focus away, it will no longer loop.) Actual Results: . Expected Results: Once it reaches a steady state, it should not keep calling Application::Yield() all the time while nothing happens. Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/604.4.7 (KHTML, like Gecko) Version/11.0.2 Safari/604.4.7
Any relation with bug 104030?
Possibly.
Created attachment 139495 [details] Possible solution I might found the cause (or a clue). The problem will disappear when commenting out the following lines. diff --git a/vcl/osx/salnativewidgets.cxx b/vcl/osx/salnativewidgets.cxx index d311526c0168..32f940516bd5 100644 --- a/vcl/osx/salnativewidgets.cxx +++ b/vcl/osx/salnativewidgets.cxx @@ -64,10 +64,10 @@ public: { if( AquaSalFrame::isAlive( mpFrame ) && mpFrame->mbShown ) { - mpFrame->maBlinkers.remove( this ); - mpFrame->SendPaintEvent( &maInvalidateRect ); + // mpFrame->maBlinkers.remove( this ); + // mpFrame->SendPaintEvent( &maInvalidateRect ); } - delete this; + // delete this; } }; More in general, what does Aquablink do? Creating a glow button or something like that? I didn't notice any difference without it (patch attached). Note: I didn't delete the reference in schedule
Apparently, back in the days, the default button of dialogs in Mac OS X did "pulsate" or "blink". See https://arstechnica.com/gadgets/2000/02/mac-os-x-dp3/4/ . Apparently our code for that was introduced in 2007, in 58647e72cf6e84a8dd0645fa6c1f27704d7ce9c0 , INTEGRATION: CWS aquavcl03 (1.3.2); FILE MERGED . One line of that commit message says "2007/09/28 15:10:15 pl 1.3.2.15: blinking default button". In https://wiki.openoffice.org/wiki/Log_Mac_Meeting_October_4th_2007 one sees "even the buttons are animated now ;-) Thanks PL!" But as these things tend to go, I wouldn't be surprised if around the same time that OOo started providing support for pulsating buttons, Mac OS X stopped doing that;) So yeah, most likely that Aquablink crack is completely unnecessary now. Thanks!
I am told on IRC that OS X stopped having pulsating default buttons only in 10.10, and as LO supports 10.9 or newer, possibly the code is actually useful still. (But I doubt those who do run LO on 10.9 would be awfully disappointed if the blinking disappeared... Also, we could well bump the minimum OS version to 10.10 by LO 6.1, IMHO.)
*** Bug 104030 has been marked as a duplicate of this bug. ***
(In reply to Tor Lillqvist from comment #5) > I am told on IRC that OS X stopped having pulsating default buttons only in > 10.10, and as LO supports 10.9 or newer, possibly the code is actually > useful still. (But I doubt those who do run LO on 10.9 would be awfully > disappointed if the blinking disappeared... Also, we could well bump the > minimum OS version to 10.10 by LO 6.1, IMHO.) Any change to get a bump the minimum OS version to 10.10 or even 10.11 for LO6.3? Mavericks getting old by now.. Not that I'm in a hurry.. And maybe a bump in compiler baseline too.. even if this isn't needed compiler wise (http://document-foundation-mail-archive.969070.n3.nabble.com/Compiler-baselines-was-Libreoffice-qa-minutes-of-ESC-call-td4244437.html#a4248710) The last XCode bump did break some stuff on MacOS side (if I remember correctly; page orientation while printing).
Bumping the minimum required version to 10.10 or 10.11 would be fine with me, but I don't decide these things.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/c76160c6e23f8a4e8d60068b7054591f238cbc9f%5E%21 tdf#114839: Drop ancient AquaBlinker crack It will be available in 6.3.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.
@Tor Lillqvist, thanks for fixing this issue. Should it be cherry-picked to 6.2 branch ?
Well, I guess at least the bump of minimum macOS to 10.9 can not be done for 6.2, as it would come as a SURPRISE to both the LibreOffice users who still run 10.9, and we can't have that, can we? So in theory, assuming that the "pulsating" thing actually works on 10.9 thanks to this code that was removed, removing it in 6.2 would be a REGRESSION!!!