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.
I can confirm this with LO 4.1.1. on Windows 7 SP1
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.1 or preferably 5.0.2.2 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-10-14
(In reply to QA Administrators from comment #2) Problem still present with version 4.4.5.2 on Windows 7.
Hello. Tested with Version: 5.0.3.1 Build ID: fd8cfc22f7f58033351fcb8a83b92acbadb0749e Locale: es-MX (es_MX) In Windows XP SP3 adding screenshoot
Created attachment 119805 [details] Screenshot on Windows XP SP3
Created attachment 119806 [details] screenshoot in windows 10
*** Bug 91279 has been marked as a duplicate of this bug. ***
Migrating Whiteboard tags to Keywords: (needsDevEval, topicUI) [NinjaEdit]
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170103
This is not an issue in 5.2.4.2. Thank you!
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.
Created attachment 130132 [details] Test file 1
Created attachment 130133 [details] Test file 2
Created attachment 130134 [details] Screenshots and descriptions
Tested in Windows XP SP3 and Windows 10
Problem still present in LO version 5.2.4.2 (Windows7)
There was a fix to a related bug, maybe you could test: http://dev-builds.libreoffice.org/daily/master/Win-x86@42/current/
(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 would like to, but I won't have an opportunity to do it soon.
(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.
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?
*** Bug 108023 has been marked as a duplicate of this bug. ***
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.
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.
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.
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.
(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
*** Bug 72124 has been marked as a duplicate of this bug. ***
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.
(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?)
I can't reproduce the issue anymore with version: 6.0.4.2 (x64, Windows 10.0). But please another one should also test. @Winfried: Do you still have this problem?
I can't reproduce the issue anymore with version: 6.0.4.2 (x64, Windows 10.0). But please another one should also test. @Winfried: Do you still see this problem?
(In reply to Thomas Lendo from comment #33) > I can't reproduce the issue anymore with version: 6.0.4.2 (x64, Windows > 10.0). But please another one should also test. > > @Winfried: Do you still see this problem? I confirm that the problem is gone with version 6.0.6.2 (x64, Windows 10).
As there are commits towards this report, let's set to FIXED.
Hi. Tested in Versión: 6.1.2.1 (x64) Id. de compilación: 65905a128db06ba48db947242809d14d3f9a93fe Subprocs. CPU: 8; SO: Windows 10.0; Repres. IU: predet.; Configuración regional: es-MX (es_MX); Calc: CL Works OK.