Bug 16946 - Non-ASCII keyboard layouts are sometimes available in password fields and vice versa
Summary: Non-ASCII keyboard layouts are sometimes available in password fields and vic...
Status: RESOLVED WORKSFORME
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.5
: P1 Major
Assignee: Nobody
URL: http://www.youtube.com/
Keywords: HasReduction, InRadar
Depends on:
Blocks:
 
Reported: 2008-01-20 00:53 PST by mitz
Modified: 2009-06-26 12:47 PDT (History)
1 user (show)

See Also:

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 an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description mitz 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>.
Comment 1 mitz 2008-01-20 00:54:13 PST 
<rdar://problem/5696689>
Comment 2 mitz 2008-01-20 00:59:21 PST 
Created attachment 18563 [details]
Test case
Comment 3 mitz 2008-01-20 01:22:33 PST 
Using bisect-builds on the test case I get:
Works: r27021  Fails: r27031
which makes no sense.
Comment 4 mitz 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.
Comment 5 mitz 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.
Comment 6 Alexey Proskuryakov 2008-01-20 14:38:52 PST 
I could reproduce on 10.5.1 with shipping Safari/WebKit.
Comment 7 mitz 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.
Comment 8 Alexey Proskuryakov 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.
Comment 9 mitz 2008-08-18 17:34:27 PDT 
Alexey, does your patch for bug 19347 fix this one too?
Comment 10 Alexey Proskuryakov 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.
Comment 11 Alexey Proskuryakov 2009-06-26 12:47:08 PDT 
Looks like this is all fixed in ToT as of r44941.