I have a password protected spreadsheet, which I need to open and edit sometimes. It worked fine for a long time, but recently when I open it LO completely loses keyboard input to all of its windows when the password prompt disappears. After I close all LO windows and reopen, the keyboard is back.
LibreOffice 22.214.171.124 on Debian unstable, KDE 4.8.4
Is this still an issue in the latest stable release?
It is still an issue with LO 4.0.3 and KDE 4.10.2. The password input dialog always makes LO lose keyboard input, but there are some other random occasions when it happens. It is mostly related to dialogs, like renaming a worksheet.
This issue is still present with current versions: LO 126.96.36.199, KDE 4.10.5.
The problem seems to occur with all dialogs that have a text input field, e.g. renaming a sheet in Calc, but it doesn't always happen. The password dialog always triggers the issue. When such a dialog is opened again, the dialog has keyboard input, but the main LO window has not.
could you try to upload a dummy password-protected .ods?
is the bug happening just with the file you are using or with any password-protected file?
Created attachment 90608 [details]
Password is "password".
I have a hunch that this problem stems from interaction with iBus, but I didn't have time to test it yet.
are you maybe complaining that once the password dialog pops out you cannot enter any text in other LibO windows, until you close the password dialog?
is it this the bug you are talking about?
(In reply to comment #6)
> are you maybe complaining that once the password dialog pops out you cannot
> enter any text in other LibO windows, until you close the password dialog?
> is it this the bug you are talking about?
No. After the password dialog has been dismissed, no keyboard input is registered in any of the LO windows until I close them all, and start LO again. This makes working on password protected documents impossible.
Ok, I understand. So bug is not reproducible with LibO 188.8.131.52 under Win7 64bit.
probably a Linux specific issue. changed platform field
This bug is not reproducible on Ubuntu 13.10 amd64 with LXDE.
(In reply to comment #7)
> (In reply to comment #6)
> > @almos
> > are you maybe complaining that once the password dialog pops out you cannot
> > enter any text in other LibO windows, until you close the password dialog?
> > is it this the bug you are talking about?
> No. After the password dialog has been dismissed, no keyboard input is
> registered in any of the LO windows until I close them all, and start LO
> again. This makes working on password protected documents impossible.
NOREPRO on Ubuntu 12.04.3 + LO 184.108.40.206.
Might be a KDE problem?
LO Version: 220.127.116.11, installed from ubuntu repositories
ubuntu 13.10 with the unity desktop, amd64
i'm not using the unity menubar integration (ie apt-get purge libreoffice-gtk,
because the integration breaks menu mnemonics, ie alt-f doesn't work)
any time i cancel a dialog, there's about a 50% chance that i'll lose the ability to enter any keyboard data in any LO window. it's possible that this happens sometimes when i select something other than cancel, but i haven't verified that
i'm not using password protection on anything, but it sounds like the same bug that almos is seeing, as he says "there are some other random occasions when it happens"
i believe i'm not using any KDE anything (atleast "ldd soffice.bin | grep kde" doesn't return anything, and nothing with "k" in it looks suspicious)
almos: Any news about this problem when using LO 18.104.22.168?
Now I installed LO 22.214.171.124 (the package version is 1:4.2.2~rc1-1) from experimental, and the problem is still there. Current KDE version is 4.11.5.
I'm seeing the same problem on a new Xubuntu 14.04 32-bit installation. Open password-protected spreadsheet, enter password, spreadsheet appears but Calc accepts no keyboard input. All Calc windows exhibit same behavior until closing and reopening them.
Running LibreOffice Calc installed from Ubuntu, version string:
Same thing happening here. Libreoffice calc. Sometimes when I open a protected xml-ods I´m not able to type anything in the password window and sometimes I can't do it in the sheet. Any idea? Thanks
set status to NEW because of 2 independent confirmations in comments above
I may have a related problem:
When I have a Writer document open, then open a database with Base, then fill in login/pw in the dialog box (I have a postgresql backend) I cannot type anymore in the Writer window, enter anything in a Base table, form etc.
However, I can still navigate in the Base main window (select a table/form, press enter to open it).
As far as I can tell this happens after the login dialog. Closing all Libreoffice windows makes the problem go away.
This is new with LO 126.96.36.199 from the Libreoffice PPA, Kubuntu 14.04 + Kubuntu Updates PPA (KDELibs 4.13.2, Qt 4.8.6).
On another machine (x86 instead of amd64) I don't seem to have this problem. Missing dependancy? Will investigatw further.
1) On the same computer the problem with both the password protected spreadsheet and the login dialog for the pg database happen. This means this problem still occurs (or has reapeared in) 188.8.131.52
2) the keyboard only gets stuck when you complete the password by pressing enter. The problem does not occur when after typing the password click OK. This explains why #2 it seems to not reproduce.
Now I will go back to my other machines to verify if this problem occurs in the same way as well.
On my 3 (almost identical Kubuntu) machines, the problem occurs only on one. However, on that one it happens consistently.
It might be a missing dependency.
When starting LO from the command line on the machine with the problem, when opening secret.ods get:
X Error: BadMatch (invalid parameter attributes) 8
Major opcode: 42 (X_SetInputFocus)
Resource id: 0x64006c7
The other machines give not errors.
This problem goes away when removing the package libreoffice-kde
A difference in startup behavior that might be a clue to what's going wrong:
With libreoffice-kde when clicking on secret.ods in dolphin, LO starts with the password dialog *behind* all other windows.
Without libreoffice-kde (but with libreoffice-gnome/gtk/gtk3) LO starts with the password dialog *in front* all other windows.
It might have something to do with grabbing the focus.
Now the only puzzle: why on my other machines with libreoffice-kde the problem does not occur.
I don't have libreoffice-kde installed, yet I experience this bug.
Can you config clicking OK instead of pressing ENTER is a workaround?
I tried a few times, and it seems like you're right: when pressing enter, keyboard is lost, but clicking on OK is fine. I never tried clicking OK before.
Created attachment 109464 [details]
List of most recent upgrades prior to appearance of this bug on my system.
I have had this same problem only for the past few days. It is occurring on 2 machines - one is running Xubuntu 14.04 and the other is Kubuntu 14.04. Both of them have been running these installations for several months using password-protected .ods files with no problem.
I can confirm that clicking OK rather than pressing Enter in the password dialog is a workaround.
I attached a list of packages upgraded on 11/07. The problem seems to have appeared after that.
I can now say that the list of "suspect" upgrades which I posted a few days ago is probably irrelevant to this bug. Today I'm working at another machine running Xubuntu 14.04 (and no KDE libraries). I have done all the same upgrades to this one, but here that bug does not occur. The keyboard works normally and password-protected files can be edited as usual, regardless of whether I press Enter or click OK after entering the password.
Although both machines are running Xubuntu 14.04, there are many differences in the programs installed on the two machines -- many programs installed on one and not the other -- so maybe one of those is to blame. But I notice that there are also many differences in the contents of ~/.config/libreoffice/... on the two machines and that's surprising since in both cases LO was installed from us.archive.ubuntu.com.
This issue continues to occur, even when a newly created user creates a new test spreadsheet and saves it with a password. However, if root opens a password-protected spreadsheet that was created by any user (including root), the keyboard remains fully-functional and the spreadsheet can be edited, regardless of whether root presses Enter or clicks OK after entering the password.
Does this provide any clues?
Adding self to CC if not already on
Strangely, after a couple of weeks and for no apparent reason it began working correctly again. For at least the last 5 weeks I've been able to open and edit password-protected files without any problems. I have no idea how this happened -- certainly nothing that I did consciously.
is the bug gone for you too with latest LibO release? if yes, mark this as RESOLVED WORKSFORME
I currently have 184.108.40.206 (Kubuntu Vivid).
I have not yet tried 4.4.3.
For the spreadsheet attached to this bug report I can confirm that the bug is away.
However, when opening a Base form (#17) the problem still exists. I.e. when entering the password to the database (I am using psql sdbc driver to postgresql) followed by <enter> I can not enter anything after that, but when clicking OK no problem.
Seems one occurance of the bug is resolved the other not.
Note: you can not password protect an embedded HSQLDB. Base can however connect to a remote db that might (and most probably will) use a login/password. When opening a table or running a query the first time Base will pop up a dialog asking for the login/pw. This is the dialog causing the trouble.
(In reply to Ferry Toth from comment #33)
> I currently have 220.127.116.11 (Kubuntu Vivid).
> I have not yet tried 4.4.3.
> For the spreadsheet attached to this bug report I can confirm that the bug
> is away.
so RESOLVED WORKSFORME
> However, when opening a Base form (#17) the problem still exists. I.e. when
> entering the password to the database (I am using psql sdbc driver to
> postgresql) followed by <enter> I can not enter anything after that, but
> when clicking OK no problem.
> Seems one occurance of the bug is resolved the other not.
I think the best thing is to move on from this long report and file a new clean one about the Base issue if this is still happening with latest 18.104.22.168 or 22.214.171.124 releases.
I tried with 126.96.36.199 in Debian Unstable, and this seems fixed. Thanks.
correct status is WORKSFORME since we don't know the exact committ that FIXED it.