Bug 114466 - Certain Document in Use dialog does not get focus
Summary: Certain Document in Use dialog does not get focus
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All Windows (All)
: medium minor
Assignee: Mike Kaganski
URL:
Whiteboard: target:6.1.0 target:6.0.1
Keywords:
Depends on:
Blocks: File-Lock
  Show dependency treegraph
 
Reported: 2017-12-14 14:21 UTC by Aron Budea
Modified: 2018-02-04 21:13 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot of dialog not getting focus (99.07 KB, image/png)
2017-12-14 14:21 UTC, Aron Budea
Details
Screenshot of dialog getting focus (95.26 KB, image/png)
2017-12-14 14:21 UTC, Aron Budea
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Aron Budea 2017-12-14 14:21:03 UTC
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
Comment 1 Aron Budea 2017-12-14 14:21:52 UTC
Created attachment 138446 [details]
Screenshot of dialog getting focus
Comment 2 Aron Budea 2017-12-15 03:47:05 UTC
One of the texts mentioned in the description is not correct, these are the correct ones:
STR_ALREADYOPEN_MSG, STR_OPENLOCKED_MSG
Comment 3 Aron Budea 2017-12-15 06:27:41 UTC
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)
Comment 4 V Stuart Foote 2017-12-15 15:13:28 UTC
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
Comment 5 Caolán McNamara 2017-12-17 14:19:44 UTC
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.
Comment 6 V Stuart Foote 2017-12-17 17:33:05 UTC
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
Comment 7 Caolán McNamara 2017-12-17 20:27:45 UTC
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
Comment 8 Aron Budea 2017-12-18 02:22:08 UTC
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.
Comment 9 V Stuart Foote 2017-12-18 02:49:59 UTC
(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.
Comment 10 Aron Budea 2017-12-18 05:31:17 UTC
(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.
Comment 11 V Stuart Foote 2017-12-18 17:33:47 UTC
(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
Comment 12 Aron Budea 2017-12-18 18:50:28 UTC
(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...
Comment 13 V Stuart Foote 2018-01-27 14:59:16 UTC
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.
Comment 14 Commit Notification 2018-01-29 14:19:34 UTC
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.
Comment 15 Commit Notification 2018-01-29 20:40:58 UTC
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.
Comment 16 V Stuart Foote 2018-01-30 06:16:50 UTC
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
Comment 17 Aron Budea 2018-02-03 22:13:31 UTC
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).
Comment 18 Aron Budea 2018-02-03 22:17:30 UTC
Oh, and I tested with the same daily build as the one mentioned in comment 16.
Comment 19 Commit Notification 2018-02-04 21:11:49 UTC
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.
Comment 20 Commit Notification 2018-02-04 21:13:14 UTC
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.