Bug 16946 – Non-ASCII keyboard layouts are sometimes available in password fields and vice versa

• Component: WebKit Misc.
• Status: RESOLVED WORKSFORME

Secure text entry mode is off in the password field on YouTube, but on in the search field.

Steps to reproduce:
0) In System Preferences > International enable a non-Latin keyboard layout, such as Hebrew.
1) Go to http://www.youtube.com/
2) If you are logged in to your YouTube account, log out and go back to step 1)
3) Press Tab twice to focus the password field
4) Open the Input ("flag") menu and see if Hebrew is enabled
5) Press Tab again to focus the search field
6) Open the Input menu again and see if Hebrew is enabled

Results:
Hebrew is enabled when the password field is focused but not when the search field is focused. It should be the other way around.

Regression:
Safari 3.0.4 behaves correctly. I suspect <http://trac.webkit.org/projects/webkit/changeset/29581>.

<rdar://problem/5696689>

Created attachment 18563 [details]
Test case

Using bisect-builds on the test case I get:
Works: r27021  Fails: r27031
which makes no sense.

I am now able to reproduce the bug occasionally with even earlier revisions, so I am not sure that this ever worked correctly on Leopard.

Created attachment 18568 [details]
Test case

Added the ability to see what you type into the password field.

[Alexey Proskuryakov]

I could reproduce on 10.5.1 with shipping Safari/WebKit.

Using the debugger I can see that WebKit is making the right calls, so I suspect the problem is that TSMSetDocumentProperty() and TSMRemoveDocumentProperty() do not always behave as expected. With Alexey's help we have discovered that there are also differences in reproducibility (and ability to type non-ASCII text into the password field) depending on whether you use the Input menu or keyboard shortcuts to switch between input methods.

[Alexey Proskuryakov]

I think that we're making the right calls, but with wrong arguments, as TSMGetActiveDocument() gives us unexpected results. The bug is somewhat confusing, as there are different behaviors depending on how you switch between input methods.

Alexey, does your patch for bug 19347 fix this one too?

[Alexey Proskuryakov]

AFAICT, the original steps to reproduce work correctly now.

However, there is still at least one case when secure input is not enabled, maybe we need a new bug for it:
1. Focus a password field.
2. Switch to Finder.
3. Switch back to Safari by clicking in its window.

[Alexey Proskuryakov]

Looks like this is all fixed in ToT as of r44941.