16946 2008-01-20 00:53:03 -0800 Non-ASCII keyboard layouts are sometimes available in password fields and vice versa 2009-06-26 12:47:08 -0700 1 1 1 Unclassified WebKit WebKit Misc. 528+ (Nightly build) Mac OS X 10.5 RESOLVED WORKSFORME http://www.youtube.com/ HasReduction, InRadar P1 Major --- 1 mitz webkit-unassigned ap oldest_to_newest 67775 0 mitz 2008-01-20 00:53:03 -0800 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>. 67776 1 mitz 2008-01-20 00:54:13 -0800 <rdar://problem/5696689> 67777 2 18563 mitz 2008-01-20 00:59:21 -0800 Created attachment 18563 Test case 67778 3 mitz 2008-01-20 01:22:33 -0800 Using bisect-builds on the test case I get: Works: r27021 Fails: r27031 which makes no sense. 67789 4 mitz 2008-01-20 14:05:50 -0800 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. 67791 5 18568 mitz 2008-01-20 14:24:04 -0800 Created attachment 18568 Test case Added the ability to see what you type into the password field. 67792 6 ap 2008-01-20 14:38:52 -0800 I could reproduce on 10.5.1 with shipping Safari/WebKit. 67793 7 mitz 2008-01-20 14:41:15 -0800 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. 86541 8 ap 2008-07-21 02:34:25 -0700 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. 88777 9 mitz 2008-08-18 17:34:27 -0700 Alexey, does your patch for bug 19347 fix this one too? 88801 10 ap 2008-08-19 01:04:30 -0700 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. 128541 11 ap 2009-06-26 12:47:08 -0700 Looks like this is all fixed in ToT as of r44941. 18563 2008-01-20 00:59:21 -0800 2008-01-20 14:24:04 -0800 Test case 19468 reduction.html text/html 189 mitz PHA+CiAgICBUYWIgaW50byB0aGlzIGZpZWxkOiA8aW5wdXQgdHlwZT0icGFzc3dvcmQiPiAoc2Vj dXJlIGtleWJvYXJkIGVudHJ5IG1vZGUgc2hvdWxkIGJlIG9uKQo8L3A+CjxwPgogICAgYW5kIG5v dyBpbnRvIHRoaXMgZmllbGQ6IDxpbnB1dD4gKHNlY3VyZSBrZXlib2FyZCBlbnRyeSBtb2RlIHNo b3VsZCBiZSBvZmYpCjwvcD4K 18568 2008-01-20 14:24:04 -0800 2008-01-20 14:24:04 -0800 Test case 16946 reduction.html text/html 279 mitz PHA+CiAgICBUYWIgaW50byB0aGlzIGZpZWxkOiA8aW5wdXQgdHlwZT0icGFzc3dvcmQiIG9uaW5w dXQ9InR5cGVkVGV4dC5pbm5lclRleHQgPSB2YWx1ZTsiPiAoc2VjdXJlIGtleWJvYXJkIGVudHJ5 IG1vZGUgc2hvdWxkIGJlIG9uOyB2YWx1ZTogJmxkcXVvOzxzcGFuIGlkPSJ0eXBlZFRleHQiPjwv c3Bhbj4mcmRxdW87KQo8L3A+CjxwPgogICAgYW5kIG5vdyBpbnRvIHRoaXMgZmllbGQ6IDxpbnB1 dD4gKHNlY3VyZSBrZXlib2FyZCBlbnRyeSBtb2RlIHNob3VsZCBiZSBvZmYpCjwvcD4K