Created attachment 138445 [details] Screenshot of dialog not getting focus Prerequisites: - LibreOffice needs to be associated as default program for opening ODT files. - A lock file has to be prepared for an existing document (copy it when the document is open, close it, and copy the lock file back). - Change user name in the lock file to something else (field between first two commas). Repro steps: - Open Writer, open a different document, and minimize it. - In a file manager (eg. Explorer) double click the document with the prepared lock file. => Seemingly nothing happens, the Document in Use dialog isn't shown. Once the Writer window is restored, the dialog can be seen in front. The dialog pops up/gets the focus normally if the profile location is changed in the lock file instead of the user name (last field, before the semicolon). Actually, the window doesn't have to be minimized, in one case it gets the focus and pops up in front of any application window, in the other it doesn't. See attached screenshots. Interestingly, if no document is opened in the background, then the dialog gets the focus in both cases. Observed using LO 5.4.4.2 / Windows 7. Might be Windows only. Seems somewhat similar to bug 49134. For reference, one dialog is AlreadyOpenQueryBox, the other is LockFailedQueryBox (based on the texts, STR_ALREADYOPEN_MSG and STR_LOCKFAILED_MSG). https://opengrok.libreoffice.org/xref/core/uui/source/iahndl-locking.cxx
Created attachment 138446 [details] Screenshot of dialog getting focus
One of the texts mentioned in the description is not correct, these are the correct ones: STR_ALREADYOPEN_MSG, STR_OPENLOCKED_MSG
A way to test this without having to mess with default programs is to open LO from command line, and give the file name with path in parameter. - First open the "other" document with the intended LO version. - Make sure the command line covers the LO window. - Try to open the document with the prepared lock file from command line. (might need to be done twice, the dialog seems to take focus and come to front on first try in older versions)
This class of helper dialog ("Document in use" dialog here and the "Enter Password" dialog as in bug 49134) do not seem to get the same ToTop for a document frame (LoadEnv::impl_makeFrameWindowVisible) as Mark H. did for bug 48300 [1] Can the dialogs be handled in a similar fashion to force focus and ToTop? =-ref-= [1] https://cgit.freedesktop.org/libreoffice/core/commit/?id=e9230b2b09a8dc0ea71263a1c321f4f63a222ac9 [2] https://opengrok.libreoffice.org/xref/core/framework/source/loadenv/loadenv.cxx?a=true#1611
This is set as "Inherited from OOo" and marked as a regression at the same time which seems a bit contradictory. Are the screenshots from a recent master ?, what I think I expect to see at this moment in master is that the blank window which will become the new document should appear first when there is a warning dialog, i.e. that the warning dialog is a child of that new document window , rather than what seems to be the case here that the warning dialog is a child of a previous document window, and in that case I'd hope that the new document window would already be "at-front" along with its modal blocking warning dialog.
Hmm, as for bug 49134 with current Windows master (containing commit [1] ) installed "msiexec.exe /i", and "WRITE_REGISTRY=1" on opening a locked document a new blank document frame will be created infront of Windows Explorer, and the in-use dialog will open with focus in front of the blank LO document frame. So guess this is a WFM =-ref-= bug 113160 - http://cgit.freedesktop.org/libreoffice/core/commit/?id=c46f0c9f6eb07db061d2f99c61c9ea05644a78ec testing Windows 10 Home 64-bit en-US with Version: 6.1.0.0.alpha0+ (x64) Build ID: 77adb770164fd703a31d8e828d777a4f827a5407 CPU threads: 4; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2017-12-17_03:10:29 Locale: en-US (en_US); Calc: group threaded
yes, that sounds to me that the new behaviour of making warning dialogs during load modal to the new document frame they are relevant for, and making that frame visible before doing that, has a virtuous knockon effect
The regression keyword was my mistake, I thought it was working fine in sometimes around 4.0, but it was only a little different. (In reply to V Stuart Foote from comment #6) > Hmm, as for bug 49134 with current Windows master (containing commit [1] ) > installed "msiexec.exe /i", and "WRITE_REGISTRY=1" on opening a locked > document a new blank document frame will be created infront of Windows > Explorer, and the in-use dialog will open with focus in front of the blank > LO document frame. Still occurs with fresh daily build (99210a149c859fcd683870b280adaeeffd1250e4, 2017-12-17_23:36:24). I'm using the method from comment 3. Note that if the dialog appeared once, and you clicked Cancel, then next time the dialog will appear correctly in front if you haven't switched back to LibreOffice window once, or switched back using Alt-Tab. It does appear hidden however if you switch back and forth by clicking in the LibreOffice window, and then try to open the locked document again.
(In reply to Aron Budea from comment #8) > > Still occurs with fresh daily build > (99210a149c859fcd683870b280adaeeffd1250e4, 2017-12-17_23:36:24). I'm using > the method from comment 3. Aron, hate to ask but could you double check the actual LO build that is running in the window that opens. I had to force the correct build to run using a full path to executable or using a Windows Explorer openwith picker action.
(In reply to V Stuart Foote from comment #9) > Aron, hate to ask but could you double check the actual LO build that is > running in the window that opens. I had to force the correct build to run > using a full path to executable or using a Windows Explorer openwith picker > action. Sure, no problem, I checked now, and both instances are of the same build. As I mentioned I was using the method described in comment 3, but maybe the description is not very clear: LO is started via command line from its install directory (used SI-GUI for installing separately), with the document as parameter. This should ensure the same executable is opened.
(In reply to Aron Budea from comment #10) > > Sure, no problem, I checked now, and both instances are of the same build. > As I mentioned I was using the method described in comment 3, but maybe the > description is not very clear: > LO is started via command line from its install directory (used SI-GUI for > installing separately), with the document as parameter. This should ensure > the same executable is opened. This is strange--as this really does WFM. On Windows 10 Ent 64-bit en-US using account with admin permissions. If I use the same method as comment 3: 1.Creating a sheet 2. Copying the lock file to temp. 3. Saving the sheet and closing LO. 4. Editing lockfile to change user name. 5. Copying lockfile back to directory holding the test doc. 6. launching scalc.exe with full path in folder containing the test doc. e.g. C:\LODev610_x64_20171218_TB42\program\scalc.exe tdf114466_vsfTesting1.ods Result is always: 1. blank LO frame gray background, no decoration except LO icon upper left 2. pop-up dialog "Document in Use" with details from lock file, and button options to "Open Read-Only", "Open Copy", or "Cancel" The "Document in Use" warning dialog persists until dismissed, and when open the warning asserts in front of other user interactions with the system--i.e. while I took a screen clip. Also, with this a Cancel action does not open the Start Center Window--LO Closes. Alternatively, if I first open LO to Start Center: 1. create new sheet, and alter lock file as above 2. open command prompt 3. open LO to Start Center 4. from command prompt launch scalc.exe with full path in directory holding test doc Result is always: 1. warning dialog opens with focus in front of command prompt and the open Start Center 2. the LO Start Center remains unchanged Selecting "Open Read-Only" uses the Start Center frame to hold the test doc Selecting "Cancel" drops focus onto the Start Center instance When the "Document in Use" warning dialog is open--it asserts in front of any other user interactions--including Task Manager or Resource Monitor. The "Show the Desktop" will suppress--and it will reopen with "Show Open Windows" Likewise selecting the locked test sheet from Start Center opens the warning dialog. So, this all seems to work correctly (or as Caolan intended) forcing the warning dialog to front of the new LO Window instance. Why are our results so different? My install is a typical /a administrative install, and I edit the bootstrap.ini to point profile to $ORIGIN/../Data/settings =-testing-= Version: 6.1.0.0.alpha0+ (x64) Build ID: 99210a149c859fcd683870b280adaeeffd1250e4 CPU threads: 8; OS: Windows 10.0; UI render: GL; TinderBox: Win-x86_64@42, Branch:master, Time: 2017-12-18_00:46:38 Locale: en-US (en_US); Calc: group threaded
(In reply to V Stuart Foote from comment #11) > 1.Creating a sheet > 2. Copying the lock file to temp. > 3. Saving the sheet and closing LO. > 4. Editing lockfile to change user name. > 5. Copying lockfile back to directory holding the test doc. > 6. launching scalc.exe with full path in folder containing the test doc. > e.g. C:\LODev610_x64_20171218_TB42\program\scalc.exe > tdf114466_vsfTesting1.ods Jeez, my mistake again, I mixed up the two cases in the description: - Change user name in lock file: this will behave as expected, dialog comes to front, - Change profile location in lock file: this will not, dialog stays in background (in this case the dialog shows "Open" instead of "Open Copy" in the middle). Let me write down my steps correctly this time, all this has to be repeated with the same LO installation: 1. Save an empty document. 2. Copy and edit its lock file by changing profile location (last entry), 3. Close document, copy back the lock file. 4. Start a new document, I did from command line (to have an LO window open). 5. From command line, open the existing document by giving it as parameter to soffice. => The dialog doesn't show in front. If it does, cancel out, go back to command line and try again step 5. Mind you, the behavior can be different with slightly different steps. I used to test by opening an existing document instead of an empty one in step 4. Then it mattered if you just canceled out of the dialog, or also alt-tabbed back to the previously open document, or clicked back into the previously open document. Then the bug was only reproducible with the 3rd variant. However, with an empty document this doesn't seem to matter... strange (it seems the complications of steps started in 6.0, possibly by Caolan's change). It's easy to get confused by all these tiny details that matter here...
Interesting code analysis and code snippet in https://bugs.documentfoundation.org/show_bug.cgi?id=32935#c37 for forcing these helper dialogs to front with focus.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3b57cb72ec8b47f033be5a516617ed8c752517b0 tdf#32935 tdf#49134 tdf#114466 Activate newly opened modal dialogs It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8d1d82dd63eada8faa2f6eb43ef900764a5fda62 tdf#49134 tdf#114466 Transfer privilege to become foreground process It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
With Mike K's commits of comment 14 and comment 15 none of the STR, including via command line launch of comment 3, fail. All seems correct now on Windows... Aron? =-testing-= Windows 10 Pro 64-bit en-US with Version: 6.1.0.0.alpha0+ (x64) Build ID: 3deac9691011711a3b9e50d19499c588af074d7f CPU threads: 8; OS: Windows 10.0; UI render: GL; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-01-30_03:11:54 Locale: en-US (en_US); Calc: CL
Yup, it's fixed by Mike's commit. Thanks a lot, Mike! Closing this bug as FIXED. Something interesting, though: The two dialogs still act a bit differently, the dialog that used to get focus (attachment 138446 [details]) is more intrusive, and stays in front even if you switch to different applications without dismissing it. The other dialog only stays in front if the LO window is in front. This must be because of the original difference how these dialogs are presented, and not much relevant (at most a minor annoyance).
Oh, and I tested with the same daily build as the one mentioned in comment 16.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3f4b0788ba688dbdf7d4487b7ef83edc7e81c1e8&h=libreoffice-6-0 tdf#32935 tdf#49134 tdf#114466 Activate newly opened modal dialogs It will be available in 6.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d8cf7f14a50a25127d660ec6f9790feefc031025&h=libreoffice-6-0 tdf#49134 tdf#114466 Transfer privilege to become foreground process It will be available in 6.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.