#1281 autotype german symbols failes

[Gerald Hochegger]

Hello,

I'm failing to get autotype working with german keyboard (AltGR) symbols (@, ~, ...)
The problem is described in more detail in bug#1000 - and seems to fixed.

But I'm still getting "q" instead of "@".

OS: Ubuntu 14.04 amd64
LANG: en_GB.UTF-8
keyboard: German eliminate dead keys
pwsafe: ubuntu-0.97BETA

Is this a bug or am I missing somethings ?

Thanks,
Gerald

[Saurav Ghosh]

Did it work for you earlier? Did something change on your machine recently?

Can you try toggling the "Use Alternate AutoType method" setting under
the System tab and see if it makes any difference?

[Simone S.]

I have a similar problem ("q" instead of "@") using an italian keyboard configured to use a dvorak layout.
I'm using Gentoo, LANG=it_IT.UTF-8, layout us(dvorak-alt-intl).

I built pwsafe-0.97BETA from source using this ebuild: https://453458.bugs.gentoo.org/attachment.cgi?id=400808
Using exactly the same procedure with version 0.96BETA or lower it works fine, I tested both versions with the rest of the system unchanged, today.
With the alternate AutoType method all the characters are wrong.

Thank you very much for your good work and for supporting Linux! Happy new year!

[Saurav Ghosh]

Looks like SF ate up my earlier edit. Let me try again:

Can you please attach a sample pwsafe database with characters that don't
autotype correctly in username or password field?

[Ron Obvious]

I'm having this problem too. My system is similar to the one used at the beginning of this thread (Linux, German keyboard -- more details below), but not identical.

Rebuilt pwsafe from git, still seeing it this problem. Have been living with this problem for several months now.

Sample database attached. The pasword for the database is "B@dAut0type". It only contains one entry, with the test password used below; hope that suffices (?).

Here's some perhaps interesting things I've observed: First, I've compared what happens when I autotype a test password into a text editor, and then cut-n-paste (copy to clipboard, paste from clipboard). This way I've been able to find a large number of characters which are OK, and a large number which are NOT OK:

Autotype 1234567890ß!"§$%&/()=?7890ß++#',.-;:_,-<><qeüöäÜÖÄ<><++
Clipboard 1234567890ß!"§$%&/()=?{[]}+~#',.-;:_·–<>|@€üöäÜÖÄ<>|+~

While doing this, I also managed to get this error message from pwsafe:
" There was an error autotyping. Could not get keycode for key char(…) - sym(0XAAE) - str(ellipsis). Aborting autotype. If 'xmodmap -pk' does not list this KeySym, you probably need to install an appropriate keyboard layout."

I've spent some time looking into "xmodmap -pk". Is pwsafe using this, or is this just a diagnosis procedure? If pwsafe is using xmodmap, that might explain the problem -- xmodmap seems to be rather old, dusty, and generally problematic.

In any case, some more details: I'm using Archlinux (all packages up-to-date), Gnome 3.18, and gdm. I've tested this both under vanilla gnome and gnome-wayland; that doesn't make a difference. My computer is a Lenovo ThinkPad. I have the same problem whether I'm using the built-in German ("nodeadkeys") keyboard or either of my two external keyboards (one @ home, one @ work). $LANG is en_US.utf8. Is there anything else I can tell you?

I'm built password safe using the AUR "password-safe-git" package (and yaourt), by the way. After rebuilding, the "about" box says that my password safe version is "PasswordSafe (wxWidgest) v0.98 (gaf357b+) BETA".

I've learned to live without autotype (using the clipboard a lot), so it's not as urgent as it might be, but it would be great if we could get autotype working again.

[Saurav Ghosh]

I have more questions:

1. Are you too seeing this problem with 0.97BETA and above, but 0.96BETA
   works fine for you?

2. From the Autotype/Clipboards characters you provided, the difference
   seems to start from the second set of "789..". Can you tell me how those
   digits were generated? Were they from the numeric keypad or as some
   composite keystrokes?

3. When you got the autotype error, did autotype string actually have some
   ellipsis like (three dots, like ...) character?

4. Did your you actually try the "xmodmap -pk" thing? Can you attach the
   output of your "xmodmap -pk"?

5. Can you attach the print of your keyboard layout? You can get it by
   "xkbprint :0"

Thanks.

[Ron Obvious]

1. When did the problem start? I honestly don't know anymore. If this very important? If so, I could start building old versions to find the latest version without the problem, but this would take a while, and so it seems better to answer your other questions first. So… (note the use of the ellipsis key there)…
2. Yes, the first problems are the seven characters "{[]}+~#'", which are autotyped as "7890ß++". I didn't test the numeric keypad at all, those are all generated by using the "alt" modifier key, so yes, composite keystrokes. By the way, while typing this answer, I notice that sourceforge apparently doesn't like backslashes. There is supposed to be a backslash between the right curly bracket and the plus -- backslash being alt-ß on my keyboard. The tilda is alt-plus.
3. Yes. Who knew my keyboard could do that? But in fact, alt-gr-period (i.e. right alt-period) produces an ellipsis.
4. I've attached the output from xmodmap -pk , and...
5. … and the output from xkbprint (by the way, the "alt" key is directly to the left of the space bar, and "alt-gr" is directly to the right of the space bar). Hope these files help.

Ron

P.S. Does sourceforge only allow one attachment? OK, I'll attach the output of xmodmap first, then attach the output from xkbprint afterwards.

[Ron Obvious]

And here the output from xkbprint...

[Saurav Ghosh]

Thanks for the replies. They are helpful. However, I need more information:

Please attach the outputs of

1. xmodmap -pm

2. run "xev -event keyboard > /tmp/kbevents.txt"

Then type the exact keystrokes that generate the characters are not getting
autotyped correctly. Include the ellipsis char also but it doesn't seem to
be related to the general autotype problem you're facing. Once you are
done, please kill the xev window and attach the /tmp/kbevents.txt file.
Please actually type those keys like you'd type them in a document or the
browser, even if it seems repetitive or redundant, because there may not be
1:1 correspondence between what you type and the events X generates.

1. xkbprint -nkg 2 :0

Just to rule things out

1. Your keyboard layout looks like one of these, right?

https://en.wikipedia.org/wiki/German_keyboard_layout

1. You didn't copy your pwsafe build from some other machine or a previous
   version of the OS, did you?

2. No other platform tools are messing with keyboard mappings, like any
   settings in keyboard preferences widget?

3. If you have multiple keyboard layouts (like attached screenshot), can
   you please reorder them and see if that makes any difference? I'm not
   proposing that as the solution: you can revert back to your original order
   of kb layouts once done.

Thanks,
Saurav.

[Saurav Ghosh]

Here's the screenshot I mentioned:

[Ron Obvious]

Gotta love the javascript here -- I had written a long text here, but lost it when I clicked on the screenshot of the keyboard preferences to double-check something there... :-(

So, one more time... I've prepared a tarball with all the files you've requested, plus a few others as well:
* The output from "xmodmap -pm"
* The output from "xmodmap -pk" (previously requested, so you'll have all of this in one place"
* The output from "xkbprint -nkg 2"
* The previous output from xkbprint
* The output from "xev -event keyboard"
* The safe with the bad password, AND with a new "entry", with a new bad password, containing only bad characters (not a mix of good and bad). The ellipsis is not there; only keys which password-safe accepts, handles correcly vis-a-vis the clipboard, but not autotype.
* A text file containing "notes to myself", lots of output from password-safe autotype, plus clipboard --- hopefully it will be self-explanatory, but if not, ignore it.
* A screen shot, similar to yours, showing only one keyboard layout (but note the difference between Gnome-3 and Unity or whatever you're using).

Now, as to your questions:
* Same keyboard as the picture from Wikipedia? Yes. Ironically, much closer since today than it was up until now; For reaons entirely unrelated to password-safe, I bought a new (but very old-fashioned) keyboard (and mouse) today -- a Cherry Keyboard, very much like the one in the picture in Wikipedia. Only exceptions, apart from color, are alt-gr 4, 5 and 6 (as far as I can see). So now I can test password safe on 3 different external keyboards, plus the notebooks's built-in keyboard -- and they all produce the same behavior.
* I normally use "Gnome Tweak-Tool" to re-enable ctl-alt-backspace, and disable the caps lock key. I reverted those two settings and it didn't help (by the way).
* No, I'm not using different keyboard layouts. Only one. See screenshot in tarbar.

Hope all this helps!?!

Ron

[Saurav Ghosh]

This is my fourth attempt at getting this posted on SF, which just silently
dropped my last 3 posts on the floor without any error message or a trace
of what could be wrong. Let's see if posting via email works.

Anyway, please see if the attached patch fixes autotype for you. If it
doesn't, please send me the debugging information as described in the
commit messages in the patch.

The patch should apply to c7a1132. Just "git am patchfile" should do it.

[Ron Obvious]

That did the trick.
I applied "autotype.patch" (with git am autotype.patch), rebuilt, and now autotype is working again, as well as it ever did.

Thank you very much!

Now, not to seem ungrateful, but I have two questions before we close this ticket:
(1) When will this patch join the main source tree, i.e. how will I know when I can rebuild without manually applying the patch?
(2) While autotype works, "browse to URL + autotype" (from the context menu) doesn't work. Never has worked (for me), so that's not too surprising. I seem to remember looking to see if that was a "known bug" way back when, but I can't remember what I found. In any case, is there any point opening a ticket about that? I assume that it would be incorrect to pursue that here, in this ticket, but is it worth pursuing at all -- i.e. is there any chance that "browse to URL + Autotype" might become available?

[Saurav Ghosh]

(1) It will be in the main tree in next few days. The next Linux release
would definitely have it. I guess the only way to know if the tree has this
fix would be to look at the git commit logs and see if something relevant
is there since the last release. I will try to remember to put something
like "German Autotype Fix" in the PR to Rony (the main tree maintainer).

(2) Browse to URL + Autotype was never implemented. In large part because
we don't know how to detect if the browser has finished loading the URL for
us to start autotyping. So no point in creating a ticket, I guess.

[Saurav Ghosh]

This fix is now in the main source tree (commit # 4b3620a). This bug report can now be closed.

If anything doesn't work, please re-open this one.

[Rony Shapiro]

Many thanks to sauravg for his work on this.
The package with the fix may be downloaded from https://github.com/pwsafe/pwsafe/releases/download/0.98.1BETA/passwordsafe-ubuntu-0.98.1BETA.amd64.deb
or
https://sourceforge.net/projects/passwordsafe/files/Linux-BETA/0.98.1/passwordsafe-ubuntu-0.98.1BETA.amd64.deb/download