Description: When a file is attached to an eMail (in Apple-Mail on my mac), and I klick it - when LibreOffice is already running and any other file is already open - the modal dialog does NOT appear, asking me, if I want to open the file read only, but it is hidden behind the opening window, which shows only an empty grey frame, as the file is not yet loaded. I have to drag the window away to make the modal dialog visible, klick "Open Read only" there and then the file opens as expected. Steps to Reproduce: 1. Start LibreOffice 2. Open any file (which opens normal) 3. Klick a file for which I have no write-permission (email-attachment) Actual Results: Modal window hidden behind empty frame of new window Expected Results: Modal window to show up in front Reproducible: Always User Profile Reset: Yes Additional Info: Version: 7.5.8.2 (X86_64) / LibreOffice Community Build ID: f718d63693263970429a68f568db6046aaa9df01 CPU threads: 4; OS: Mac OS X 12.7.4; UI render: default; VCL: osx Locale: de-AT (de_AT.UTF-8); UI: en-US Calc: threaded [Information automatically included from LibreOffice] Locale: en-US Module: TextDocument [Information guessed from browser] OS: Mac OS X (All) OS is 64bit: no
This Bug did not exist in Version 7.1.5.2
Further more, after the modal dialog is closed, the new window does not come to front but stays hidden behind other windows.
Hermann, is the bug also present in actual version of LO (LO 24.2.2 or actual master)? => NEEDINFO
Yes, I already tried Version 24.2.2 and so stayed with version 7.1.5.2, the last I found where this bug is not in.
Which window? Can you make a screenshot, please? Nowadays, we do have a blue bar at the top of the document and opens by default in read-only mode. Or is it some configuration?
Created attachment 195543 [details] Screenshot This is the screenshot I was asked by Dennis Roczek to supply. It shows, that there was already a LibreOffice window open, when I double-clicked the attachment in AppleMail (window in the background). Then there came up the empty gray window, which I had to shift away to see the alertbox. When trying this out today (with the newest LibreOffice version 24.3.5) I realized, that the alert-box moves with the window opend first, not with the grey one (which get's content, when I confirm the alertbox). Maybe this explains, why it did not come to the front, but stayed behind the grey window.
confirming using Version: 24.2.5.2 (X86_64) / LibreOffice Community Build ID: bffef4ea93e59bebbeaf7f431bb02b1a39ee8a59 CPU threads: 4; OS: macOS 11.7.10; UI render: Skia/Raster; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded AND using Apple Mail (works fine in Thunderbird)
(In reply to Dennis Roczek from comment #7) > confirming using > Version: 24.2.5.2 (X86_64) / LibreOffice Community > Build ID: bffef4ea93e59bebbeaf7f431bb02b1a39ee8a59 > CPU threads: 4; OS: macOS 11.7.10; UI render: Skia/Raster; VCL: osx > Locale: de-DE (de_DE.UTF-8); UI: en-US > Calc: threaded > > AND > using Apple Mail (works fine in Thunderbird) well, no warning at all in Version: 2022.7 Professional Edition...
Hi Patrick, is this something for you? Some modal window nasty behavior and only when using Apple Mail. If not, simply ignore my CC and sorry for the disturbance, but I even tested it in neooffice which does have a complete different behavior, thus you touched the code already! Best Dennis
(In reply to Dennis Roczek from comment #9) > is this something for you? Some modal window nasty behavior and only when > using Apple Mail. If not, simply ignore my CC and sorry for the disturbance, > but I even tested it in neooffice which does have a complete different > behavior, thus you touched the code already! I cannot reproduce this bug. The "open read only" dialog is always the front-most window and the existing document window is the next behind the dialog and the new, empty window is the back-most window. I am running macOS Sequoia so maybe Apple fixed something after macOS Big Sur: Version: 24.2.5.2 (AARCH64) / LibreOffice Community Build ID: bffef4ea93e59bebbeaf7f431bb02b1a39ee8a59 CPU threads: 8; OS: macOS 15.0; UI render: Skia/Metal; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded
uhm, yeah, indeed: Apple changed a lot! in 12.7 Version: 24.2.4.2 (X86_64) / LibreOffice Community Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2 CPU threads: 4; OS: macOS 12.7.5; UI render: Skia/Raster; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded the attachments were directly editable (so hitting cmd+s saves the attachment in the email!) but in 14.5 the modal dialog plops up in the front. Version: 24.2.4.2 (X86_64) / LibreOffice Community Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2 CPU threads: 4; OS: macOS 14.5; UI render: Skia/Raster; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded So basically I would say, this is NOT_OUR_BUG. @Hermann: any specific reason not upgrading macos to 12.7.5?
(In reply to Hermann Steier from comment #4) > Yes, I already tried Version 24.2.2 and so stayed with version 7.1.5.2, the > last I found where this bug is not in. commit 8ecf3fe5b28ce8fdf963c383edee683a617b3c5d Author: libreoffice <libreoffice@libreoffices-Mac-mini.local> Date: Wed Apr 14 15:15:59 2021 +0200 source 618cb39b558b7e3f9a6f2aa8cf0a935602118388 source 618cb39b558b7e3f9a6f2aa8cf0a935602118388 LibreOffice.app/Contents/Frameworks/libvcllo.dylib | Bin 11753332 -> 11753332 bytes LibreOffice.app/Contents/Resources/setuprc | 2 +- LibreOffice.app/Contents/Resources/versionrc | 2 +- 3 files changed, 2 insertions(+), 2 deletions(-) --> https://git.libreoffice.org/core/+/618cb39b558b7e3f9a6f2aa8cf0a935602118388 commit 618cb39b558b7e3f9a6f2aa8cf0a935602118388 [log] 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 tree 16dae744c3ba2458f5c0ba2deaf2dac220e4ad8b parent 18a0a72a94cd386b9f784a6bb7925a47c45e6e0b [diff] tdf#141141 sync SalFrame::GetFrameWeld and weld::GetPopupParent so they both use the same FrameWindow Change-Id: I7c58a4f2c8e82abc45eaf1dfee8eb2720503ecc7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113209 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> So I'm able to bibisect it.
Looks to me that we don't end up with the expected frame as the parent for the dialog. If I'm reading this right, then https://gerrit.libreoffice.org/c/core/+/171104 would fix it.
(In reply to Dennis Roczek from comment #11) > uhm, yeah, indeed: Apple changed a lot! > > in 12.7 > Version: 24.2.4.2 (X86_64) / LibreOffice Community > Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2 > CPU threads: 4; OS: macOS 12.7.5; UI render: Skia/Raster; VCL: osx > Locale: de-DE (de_DE.UTF-8); UI: de-DE > Calc: threaded > > the attachments were directly editable (so hitting cmd+s saves the > attachment in the email!) > > > > > but in 14.5 the modal dialog plops up in the front. > Version: 24.2.4.2 (X86_64) / LibreOffice Community > Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2 > CPU threads: 4; OS: macOS 14.5; UI render: Skia/Raster; VCL: osx > Locale: de-DE (de_DE.UTF-8); UI: de-DE > Calc: threaded > > So basically I would say, this is NOT_OUR_BUG. > > > @Hermann: any specific reason not upgrading macos to 12.7.5? Thank you Dennis! I have already upgraded to 12.7.5. (more does my hardware not support) and the problem still persists unchanged.
(In reply to Caolán McNamara from comment #13) > Looks to me that we don't end up with the expected frame as the parent for > the dialog. If I'm reading this right, then > https://gerrit.libreoffice.org/c/core/+/171104 would fix it. Thank you Caolan! Does this mean, some future version (which?) will have this problem fixed for me? Great news! I'm gonna donat to the project again.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/85511e27d259d6b19cc6c463fc06368c14511bb8 Resolves: tdf#160509 use BorderWindow client for dialog parent It will be available in 25.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.
lets backport to 24-8 at least: https://gerrit.libreoffice.org/c/core/+/171115
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/294e206ff0651d7081ac96d6c5dfc964728d86f5 Resolves: tdf#160509 use BorderWindow client for dialog parent It will be available in 24.8.1. 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 Caolán McNamara from comment #17) > lets backport to 24-8 at least: > https://gerrit.libreoffice.org/c/core/+/171115 I have submitted a backport to the 24-8-0 branch. I have also submitted a backport to 24-2 branch since Mac App Store users will likely continue to only get 24-2 releases for several more months. Hopefully those can get enough +1 votes to get include in the upcoming LibreOffice 24.2.6 and 24.8.0 releases.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/a7c155dcf7c1897ebc2f87f1227d0ebd4fc64313 Resolves: tdf#160509 use BorderWindow client for dialog parent It will be available in 24.2.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.
(In reply to Commit Notification from comment #20) > Caolán McNamara committed a patch related to this issue. > It has been pushed to "libreoffice-24-2": > > https://git.libreoffice.org/core/commit/ > a7c155dcf7c1897ebc2f87f1227d0ebd4fc64313 > > Resolves: tdf#160509 use BorderWindow client for dialog parent > > It will be available in 24.2.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. Very thnak you! Just tested the daily build of Version 4.2.6. Works fine, great!
Version 24.2.6. of course.
(In reply to Hermann Steier from comment #22) > Version 24.2.6. of course. Thank you for testing this. Marking bug as Verified/Fixed.
Unfortunately the solution seems to have produced a new problem: If I open two files and the first is hidden behind the second, and I change to Finder and double-click the first there, LibreOffice comes up to front, but with the first file still hidden behind the second. Actually only the second file (which has not been clicked in Finder) comes to front, the first file can still be hidden also by windows of other applications.
(In reply to Hermann Steier from comment #24) > Unfortunately the solution seems to have produced a new problem: > If I open two files and the first is hidden behind the second, and I change > to Finder and double-click the first there, LibreOffice comes up to front, > but with the first file still hidden behind the second. Actually only the > second file (which has not been clicked in Finder) comes to front, the first > file can still be hidden also by windows of other applications. I cannot reproduce this behavior with macOS Sequoia.
(In reply to Patrick Luby (volunteer) from comment #25) I am using Mac OS 12.7.6 as my hardware does not support more. It's astounding to me, that the problem does not exist in LibreOffice version 7.1.5.2, as I just tried out. This is the last version, for which also the former bug did not exist.