RESOLVED WORKSFORME Bug 16946
Non-ASCII keyboard layouts are sometimes available in password fields and vice versa 
https://bugs.webkit.org/show_bug.cgi?id=16946
Summary Non-ASCII keyboard layouts are sometimes available in password fields and vic...
mitz
Reported 2008-01-20 00:53:03 PST
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>.
Attachments
Test case (189 bytes, text/html)
2008-01-20 00:59 PST, mitz 		no flags
Details
Test case (279 bytes, text/html)
2008-01-20 14:24 PST, mitz 		no flags
Details
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
mitz
Comment 1 2008-01-20 00:54:13 PST
<rdar://problem/5696689>
mitz
Comment 2 2008-01-20 00:59:21 PST
Created attachment 18563 [details] Test case
mitz
Comment 3 2008-01-20 01:22:33 PST
Using bisect-builds on the test case I get: Works: r27021 Fails: r27031 which makes no sense.
mitz
Comment 4 2008-01-20 14:05:50 PST
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.
mitz
Comment 5 2008-01-20 14:24:04 PST
Created attachment 18568 [details] Test case Added the ability to see what you type into the password field.
Alexey Proskuryakov
Comment 6 2008-01-20 14:38:52 PST
I could reproduce on 10.5.1 with shipping Safari/WebKit.
mitz
Comment 7 2008-01-20 14:41:15 PST
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
Comment 8 2008-07-21 02:34:25 PDT
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.
mitz
Comment 9 2008-08-18 17:34:27 PDT
Alexey, does your patch for bug 19347 fix this one too?
Alexey Proskuryakov
Comment 10 2008-08-19 01:04:30 PDT
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
Comment 11 2009-06-26 12:47:08 PDT
Looks like this is all fixed in ToT as of r44941.
Note You need to log in before you can comment on or make changes to this bug.