Closed Bug 840406 Opened 8 years ago Closed 8 years ago
Hotmail log in screen password is exposed when entering
279.03 KB, image/png
194.94 KB, image/png
1.30 KB, patch
|Details | Diff | Splinter Review|
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20130211 Firefox/21.0 Build ID: 20130211031055 Steps to reproduce: Went to hotmail.com and entered my password. Actual results: Behavior differed based on device. (Both devices are running Firefox Nightly on Android 21.0a1 2013-02-11). On my Galaxy Nexus, you can see the password as a word suggestion (even if it's a mixture of letters, numbers and symbols). As you enter, the password becomes dots one by one. On my Nexus 7, you can see the password as a word suggestion, but also in the password text field, while typing it in. After typing the password in, there's a small delay before all text becoming dots at once. Expected results: It should behave like how it does when entering a password into GMail (See screenshot). Who uses Hotmail anyways?
Status: UNCONFIRMED → NEW
Component: General → Keyboards and IME
Ever confirmed: true
This reminds me of bug 831862; perhaps it regressed? We seem to be the only browser on Android that shows search suggestions including the pasword you type making it clearly visible. In this example, I typed 'moz' in Chrome and Nightly. If my password was 'moz' it's visible.
The behavior I see on nightly is that the password is shown whenever a non-space character is typed.
Comparison of Hotmail and Gmail behaviors. https://www.youtube.com/watch?v=glfWczoPd4c&list=PLkR5MrlefNIvHyxd35Nzkr2xY1h1d6rOl
This should have had an assignee when tracking-fennec was set. Assuming jchen is the correct owner.
Assignee: nobody → nchen
Usually, for password boxes, nsWindow::SetInputContext() is called with mIMEState.mEnabled == IMEState::PASSWORD. However, Hotmail's password box has the style "ime-mode: inactive", so nsWindow::SetInputContext() is called with mIMEState.mEnabled == IMEState::ENABLED and mIMEState.mOpen == IMEState::CLOSED. However, Android does not support IMEState::CLOSED, so in the end password mode is not used. Masayuki-san, should "ime-mode: inactive" for password fields use IMEState::PASSWORD or IMEState::ENABLED for SetInputContext()?
On Android, if the element is <input type="password">, then, you may ignore the enabled value except "DISABLED". ime-mode is introduced by IE (IIRC IE 5). And ime-mode is not supported on password. The reason why we support ime-mode on password is what our old version allows to use IME even on password field since we didn't have mechanism to control IME state. Therefore, Some users especially whose language is Cyrillic, Hebrew, Arabic or Greek, they might have used non-ASCII characters to password on some websites. If we just had changed the behavior, it would have caused a11y problem for such users. Therefore, we allowed to apply ime-mode to the password field too (i.e., we provided a way to control the password field's behavior with user style sheet). However, Gecko for Android doesn't have such historical reason. So, on Android, you don't need to respect the enabled state if the focused element is <input type="password"> except "DISABLED" state which is caused by <input type="password" readonly>. FYI: The reasons why we implemented ime-mode which is implemented only by IE are, (1) some Japanese companies usually want to control IME state for their own intranet application and (2) we needed to solve the a11y problem mentioned above.
And let me check the coming patch, please.
Attachment #721742 - Flags: feedback?(masayuki)
Comment on attachment 721742 [details] [diff] [review] Use password mode for all type=password inputs (v1) Thank you. If the state is disabled, it's returned early. So, this looks fine for me. Although, I don't familiar with the actual behavior.
Attachment #721742 - Flags: feedback?(masayuki) → feedback+
Attachment #721742 - Flags: review?(cpeterson)
Comment on attachment 721742 [details] [diff] [review] Use password mode for all type=password inputs (v1) Review of attachment 721742 [details] [diff] [review]: ----------------------------------------------------------------- LGTM. We should consider encapsulating GeckoInputConnection's mIMETypeHint, mIMEModeHint, and mIMEActionHint into an "InputHint" class. The IME hint logic is very tricky. Also, should notifyIMEEnabled() use equalsIgnoreCase() instead of equals() when checking typeHint? https://hg.mozilla.org/mozilla-central/annotate/tip/mobile/android/base/GeckoInputConnection.java#l824
Attachment #721742 - Flags: review?(cpeterson) → review+
I opened bug 848761 to handle case-insensitive type hints.
(In reply to Chris Peterson (:cpeterson) from comment #11) > I opened bug 848761 to handle case-insensitive type hints. Thanks! https://hg.mozilla.org/integration/mozilla-inbound/rev/53696679e447
Status: NEW → ASSIGNED
Target Milestone: --- → Firefox 22
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Going to hotmail.com and enter a password I can still see the password as a word suggestion. This cannot be seen when going to gmail.com -build: Firefox for Android 22.0a1 (2013-03-14) -device: Samsung Galaxy Nexus -OS: Android 4.1.1
(In reply to Andreea Pod from comment #14) > Going to hotmail.com and enter a password I can still see the password as a > word suggestion. This cannot be seen when going to gmail.com > -build: Firefox for Android 22.0a1 (2013-03-14) > -device: Samsung Galaxy Nexus > -OS: Android 4.1.1 I cannot reproduce with the latest Nightly, on the US-English, desktop hotmail.com; maybe you were on a different version of hotmail.com?
This works for me, LG Nexus 4 (Android 4.2.2) - for clarification, on visit to Hotmail I get their desktop version; their sign-in has my password masked. But ... Using another device, such as my Sony Xperia Play, the password field is not masked, you can see each character inserted for a second before it gets replaced with an asterisk. Re-opening ?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Clarification over IRC: this bug removes the word suggestions. What I'm seeing is a separate issue.
Status: REOPENED → RESOLVED
Closed: 8 years ago → 8 years ago
Resolution: --- → FIXED
Confirming that I'm not seeing the word-suggestion bar anymore.
You need to log in before you can comment on or make changes to this bug.