Description: If I attempt to open a password-protected .xlxs spreadsheet with a single click all is ok but if I use a double click the password box appears and then disappears and the document fails to open. Then I cannot open this or any other document of any type thereafter with or without password protection. I then need to close Libre Office and reopen and continue to open the .xlxs spreadsheet using a single click. I am selecting a document from The Recent Documents Tab. An .ODS spreadsheet opens OK with either a single or double click. A non-password-protected .xlxs spreadsheet opens ok with a double click. Steps to Reproduce: 1. Open Libre Office 2. From "Recent Documents" select the PW-protected .xlxs spreadsheet with a double click 3. To clear the fault, close Libre Office and reopen it, then open the PW-protected .xlxs spreadsheet with a single click only. Enter the password and the document opens OK. .ods spreadsheets with password protection open with either a single or double click OK. Actual Results: The document failed to open. Also, after attempting to open it with a double click, I can no longer open any document of any type with or without a password. To clear the fault I need to close Libre Office and reopen it, then open the document with a single click only. Expected Results: I expect both .xlxs and .ods spreadsheets that are password protected to open normally with either a single or double click. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.5.1.2 (X86_64) / LibreOffice Community Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129 CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: threaded Operating System Windows 11 Pro 64-bit CPU Intel Core i7 @ 2.50GHz 35 °C Skylake Technology RAM 16.0GB Motherboard LENOVO 1052 (U3E1) Graphics HP E232 (1920x1080@60Hz) HP E233 (1920x1080@60Hz) Intel UHD Graphics 750 (Lenovo) Storage 447GB SanDisk SSD PLUS 480GB (SATA (SSD)) 20 °C 238GB SSD 256GB (SATA (SSD)) 40 °C 476GB SAMSUNG MZVL2512HCJQ-00BL7 (Unknown (SSD)) 116GB TOSHIBA USB 3.5"-HDD (USB (SATA) (SSD)) 20 °C Optical Drives No optical disk drives detected Audio Realtek High Definition Audio
Perhaps I am misunderstanding but this sounds as if the extra click got the "enter password" dialog in some hidden background, or the whole program in some hidden background, and it is waiting for some action from the user. Since this is being reported under Windows, I should ask... Have you tried minimizing some other windows, or using [ALT]+[TAB] or using Windows Task Manager in order to bring Libreoffice Calc (or the enter password dialog) upfront? If you save and close all your open files, and in LO you go to menu Help > "Restart in Safe Mode...", is the same behavior replicated? This could also be an OS issue rather than a LibreOffice issue, so we might also need someone to replicate (or not) under other OS's. Have you had the opportunity to test this in prior versions of LO? Re-setting this to UNCONFIRMED until someone replicates this behavior.
I just tried this again. Password-protected xlxs file. Double-click to open. The password box appears very briefly and disappears, then you cannot open any document including this one. However, your suggestion that it may be hidden is true. If I then minimize Libre Office there is the password box on the desktop. Enter PW and the document opens OK. But is this the correct operation? I think not. Clive Bagshaw
Sound like PasswordDialog() in uui/source/passworddlg.cxx starting a MessageDialog. But I see no dialog flag to have it always on top or a function SetForegroundWindow(). Dialogs in particular for confirmation have to be top. IIRC there was/is some trouble on X-based window managers but at least for Windows it should be possible. (And I haven't checked the report.) Caolan, what do you think? The topic sounds as if we talked about it before.
I can't reproduce on Windows 10 and 7.5.2.2, maybe this needs Windows 11 to be reproducible. As far as I can tell the password dialog has its "Parent" set, which should be sufficient to associate it with the parent window and make it modal for that and "on top" of it. We had cases in the past with no explicit "Parent" resulting in a dialog with either an automatically picked Parent or none, which could lead to similar looking problems, but I feel this isn't one of them. Good to know if it can be reproduced on Windows 10, or if we're missing something that matters in Windows 11 wrt something like an "always-over parent" bit
File > Save As [with password] => the dialog stays on top when loading later via start center or file explorer. Cannot confirm with Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8085a68be7604e7bd00004e0d9445be5e266ffbb CPU threads: 4; OS: Windows 10.0 Build 22000; UI render: Skia/Raster; VCL: win Locale: de-DE (en_DE); UI: en-US Calc: threaded Windows 11 Pro, 22000.1696
Repro, but only with XLSX file on Windows. Commencing bibisect.
Bibisected with Windows 6.1 repo to d2f95590f478a68a4de6ef05018785523e46506b Related: tdf#115964 convert the problematic dialog to a native gtk3 one
wow, with an ods I don't see it, with an xlsx I do!
hmm, difference is that the xlsx looks for the password during type detection, which is earlier than the ods case which looks for it during the actual load, and the parent frame is set at the start of load
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7f9b3a0214e0c5d69e2becf2084fbf6e3defa090 Resolves: tdf#154308 if start center frame exists, use it as dialog parent It will be available in 7.6.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.
That solves it for me for this launched from start center case. There was no parent set for the password dialog for the xlsx case where it was launched during type detection before the window is assigned for the document. But in a start center case its baked in that the start center will be that window so we can use it as parent and things work as desired. Backport to 7.5 in gerrit also.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/b137bde5c7c7a3ce223368adfd5195dbca559155 Resolves: tdf#154308 if start center frame exists, use it as dialog parent It will be available in 7.5.3. 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.
Dear Sir or Madam, Thank you for the update. I have the following observations to make on your solution and proposed bug fix. a) going to this web link, https://dev-builds.libreoffice.org/daily/ I downloaded LibreOfficeDev_7.5.3.0_Win_x86-64 today 6th April 2023. It installed but shows in "Help, About" as version 7.5.2.2. not 7.5.3.0. Bug not fixed yet but your update does say fix will be available in next 24 to 48 hours so I will try again tomorrow, 7th April. Fri 7th April 2023 b) going to this web link, https://dev-builds.libreoffice.org/daily/ I downloaded LibreOfficeDev_7.6.0.0.alpha0_Win_x86-64 today 7th April 2023. It installed and shows in "Help, About" as version 7.6.0.0. I tested the bug -fix and I am delighted to say your bug-fix works fine. I can now double click on a password protected xlxs spreadsheet from either the MENU OPEN option or the Recent Documents option using a double click to open causing the Password Entry dialogue box to appear on top of all and successfully open the document without any problem, Well done everyone. Congratulations on a good fix. Thank you to everyone who has contributed. Great work. Clive Bagshaw c) It should be noted that the original bug as reported occurred when the p/w protected xlxs file is opened via the Menu, Recent Documents option and the p/w dialogue box briefly opened then hid behind everything to the Desktop. If the document was opened using the Menu, Open option, it did in fact open the p/w dialogue box with a double click and it remained on top of everything. I don't think I had mentioned this point about the two document opening options earlier so this is just for the record to clarify. Thank you for all your help. Best Regards,
Thanks everyone! Marking fix as "verified" by Clive.