Bug 49134 - On opening a password-protected file, the LibreOffice dialog is not raised/given focus
Summary: On opening a password-protected file, the LibreOffice dialog is not raised/gi...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.2 release
Hardware: Other All
: medium major
Assignee: Not Assigned
URL:
Whiteboard: target:6.1.0 target:6.0.1
Keywords: needsDevEval, topicUI
: 72124 91279 108023 (view as bug list)
Depends on:
Blocks: Writer-UX Password-Protected
  Show dependency treegraph
 
Reported: 2012-04-25 00:56 UTC by Winfried Donkers
Modified: 2018-02-05 09:19 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot on Windows XP SP3 (549.67 KB, image/jpeg)
2015-10-20 20:56 UTC, Robert Gonzalez MX
Details
screenshoot in windows 10 (469.77 KB, image/jpeg)
2015-10-20 21:06 UTC, Robert Gonzalez MX
Details
Test file 1 (11.90 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-01-04 03:34 UTC, Robert Gonzalez MX
Details
Test file 2 (11.24 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-01-04 03:35 UTC, Robert Gonzalez MX
Details
Screenshots and descriptions (1.05 MB, application/vnd.oasis.opendocument.text)
2017-01-04 03:36 UTC, Robert Gonzalez MX
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Winfried Donkers 2012-04-25 00:56:43 UTC
When opening a password protected odt file, a password must be entered in a dialog form before the document opens. This form is not on top of all windows on the screen, but hidden behind them.
Result is that user does know what is happening (i.e. user waits for LibreOffice dialog and Libreoffice waits for user input).

This happens when another (any) LibreOffice document is already opened, even when these opened documents are minimised on screen.

It can be reproduced in Windows XP and on OpenSUSE 11.4.
Comment 1 Teo91 2013-09-29 14:05:39 UTC
I can confirm this with LO 4.1.1. on Windows 7 SP1
Comment 2 QA Administrators 2015-10-14 19:57:47 UTC Comment hidden (obsolete, spam)
Comment 3 Winfried Donkers 2015-10-19 06:09:24 UTC
(In reply to QA Administrators from comment #2)

Problem still present with version 4.4.5.2 on Windows 7.
Comment 4 Robert Gonzalez MX 2015-10-20 20:53:55 UTC
Hello.

Tested with Version: 5.0.3.1
Build ID: fd8cfc22f7f58033351fcb8a83b92acbadb0749e
Locale: es-MX (es_MX)
In Windows XP SP3

adding screenshoot
Comment 5 Robert Gonzalez MX 2015-10-20 20:56:15 UTC
Created attachment 119805 [details]
Screenshot on Windows XP SP3
Comment 6 Robert Gonzalez MX 2015-10-20 21:06:40 UTC
Created attachment 119806 [details]
screenshoot in windows 10
Comment 7 Adolfo Jayme 2015-11-08 23:49:45 UTC
*** Bug 91279 has been marked as a duplicate of this bug. ***
Comment 8 Robinson Tryon (qubit) 2015-12-13 11:24:07 UTC Comment hidden (obsolete)
Comment 9 QA Administrators 2017-01-03 19:47:49 UTC Comment hidden (obsolete, spam)
Comment 10 Todd 2017-01-03 20:43:18 UTC
This is not an issue in 5.2.4.2.  Thank you!
Comment 11 Robert Gonzalez MX 2017-01-04 03:34:03 UTC
Hello.

I have tested this and found that it is still reproducible with Version: 5.2.4.2
Build ID: 3d5603e1122f0f102b62521720ab13a38a4e0eb0
CPU Threads: 8; OS Version: Windows 6.2; UI Render: default; 
Locale: es-MX (es_MX); Calc: group

I am attaching test files and a file with screenshots and descriptions

The steps to reproduce are:
1.-Download test files
2.-Open Windows Explorer and arrange it small and move it to the right.
3.-Double click in ProtectedFile1-20170103.ods to open
   and type password  20170103
4.-Once open, go back to Windows Explorer and refresh display with F5 to see the .~lock temp file.

5.-Double click in ProtectedFile2-20170103.ods
The enter password dialog opens back in the Windows Explorer window. When the window is maximized, the dialog stays in the background and is not visible, even using Alt – Tab, will not display the window of the “Enter password” dialog.
Refreshing the Windows Explorer window with F5, displays that the second file is opened.

So i will set this bug back to new, hoping that some one else review it.
Comment 12 Robert Gonzalez MX 2017-01-04 03:34:54 UTC
Created attachment 130132 [details]
Test file 1
Comment 13 Robert Gonzalez MX 2017-01-04 03:35:23 UTC
Created attachment 130133 [details]
Test file 2
Comment 14 Robert Gonzalez MX 2017-01-04 03:36:00 UTC
Created attachment 130134 [details]
Screenshots and descriptions
Comment 15 Robert Gonzalez MX 2017-01-04 03:36:59 UTC
Tested in Windows XP SP3 and Windows 10
Comment 16 Winfried Donkers 2017-01-04 09:26:49 UTC
Problem still present in LO version 5.2.4.2 (Windows7)
Comment 17 Buovjaga 2017-01-14 13:41:03 UTC
There was a fix to a related bug, maybe you could test: http://dev-builds.libreoffice.org/daily/master/Win-x86@42/current/
Comment 18 Winfried Donkers 2017-01-30 08:32:22 UTC Comment hidden (obsolete)
Comment 19 Winfried Donkers 2017-02-09 07:25:10 UTC
(In reply to Buovjaga from comment #17)
> There was a fix to a related bug, maybe you could test:
> http://dev-builds.libreoffice.org/daily/master/Win-x86@42/current/

I finally got to testing, using http://dev-builds.libreoffice.org/daily/master/Win-x86@42/current/ with build from 9 February.
The problem cannot be tested easily with a dev-build as the installation is not 'registered'. I could not open documents in Windows Explorer with LibreOfficeDev.
Comment 20 Dick Holford 2017-04-15 22:41:24 UTC
I am seeing a similar problem using password-protected .ods (calc) files.
LO version 5.32, Win10-1703.
Suggested cause: In my case, I normally navigate to the file using Windows Explorer, then click on it to open it in LO calc (which has been set as default).  LO then seems to create a hidden temporary file in the same folder as the file to be opened.  Is this why the password-entry box looses focus and disppears behind the Windows Explorer window?
Comment 21 Adolfo Jayme 2017-05-23 18:55:56 UTC
*** Bug 108023 has been marked as a duplicate of this bug. ***
Comment 22 Caolán McNamara 2017-12-17 14:39:17 UTC
I wonder how this now looks in master after the changes of bug #113160 ? Is there now a new blank window (which will eventually contain the contents of the new document after load) as the parent of the modal password dialog and this new window and its password dialog in the foreground. Instead of the password dialog as child of the old unrelated document window in the background.
Comment 23 V Stuart Foote 2017-12-17 17:00:45 UTC
On Windows 10 Home 64-bit en-US
with a "msiexec.exe /i", and "WRITE_REGISTRY=1" install of
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

The password dialog and new blank document frame is now raised in front of the Windows Explorer. Focus is into the password dialog.
Comment 24 Aron Budea 2017-12-18 02:27:27 UTC
Still occurs with fresh daily build for me (99210a149c859fcd683870b280adaeeffd1250e4, 2017-12-17_23:36:24).

I have the launcher open, and then open the file from command line by giving file path+name as parameter. LibrOffice window and password prompt doesn't take focus from the command line, and remains hidden behind it.
Comment 25 Commit Notification 2018-01-29 14:19:24 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 26 Commit Notification 2018-01-29 20:40:53 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 27 V Stuart Foote 2018-01-30 06:06:58 UTC
(In reply to Commit Notification from comment #25)
> http://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=3b57cb72ec8b47f033be5a516617ed8c752517b0
> 
> tdf#32935 tdf#49134 tdf#114466 Activate newly opened modal dialogs
> 

And for Windows with http://cgit.freedesktop.org/libreoffice/core/commit/?id=8d1d82dd63eada8faa2f6eb43ef900764a5fda62

tdf#49134 tdf#114466 Transfer privilege to become foreground process

Seems correct on Windows builds...

=-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 28 Aron Budea 2018-02-04 17:40:33 UTC
*** Bug 72124 has been marked as a duplicate of this bug. ***
Comment 29 Commit Notification 2018-02-04 21:11:41 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 30 Commit Notification 2018-02-04 21:13:06 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.
Comment 31 Winfried Donkers 2018-02-05 09:19:49 UTC
(In reply to Commit Notification from comment #26)
> 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.

Tested steps in comment#11 with daily build of master (tinderbox Win-x86_64@42, time 2018-02-5_04:02:41) on Windows 10pro:
-the password dialog is hidden behind the explorer window (when that is in de the center of the screen)
-the password dialog for test file 2 is on top of test file 1, so when the explorer window is out of the way, it becomes visible up on opening the document.

Because of the first behaviour I hesitate to set the bug status to resolved. (Shouldn't the current status be assigned to Mike Kaganski?)