New issue
Advanced search Search tips

Issue 848425 link

Starred by 3 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug



Sign in to add a comment

option-e does not work in input type=password fields

Reported by jared.ju...@gmail.com, May 31 2018

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Firefox/60.0

Steps to reproduce the problem:
1. Go to any website with a type=password field (Google mail, facebook, whatever)
2. Click in the password field
3. press:  Option-e, release, then press e.    

What is the expected behavior?
This should normally input é But in Chrome, it inputs e.

What went wrong?
It inputs the wrong character (does not apply the smart accent)

Did this work before? N/A 

Chrome version: 66.0.3359.181 (Official Build) (64-bit)  Channel: stable
OS Version: OS X 10.10
Flash Version: Shockwave Flash 29.0 r0

This works correctly in non-webkit/chromium based browsers like Firefox.   It's only Chrome and those that are based on the chrome rendering engine that fail to handle the smart accent keystrokes in password fields.  It also works fine in type=text fields.   So, it's just password fields with the issue.
 
Note, this is specific to the OS-X Chromium builds as far as I can tell.
Labels: Needs-Triage-M66
Cc: susan.boorgula@chromium.org
Components: UI>Input
Labels: Triaged-ET M-69 Target-69 FoundIn-69
Status: Untriaged (was: Unconfirmed)
jared.jurkiewicz@ Thanks for the issue.

Able to reproduce the issue on Mac OS 10.13.3 on the latest Canary 69.0.3446.0 and Stable 67.0.3396.62 by the steps mentioned in the original comment. Issue is not applicable for Windows 10 and Ubuntu 14.04.
Couldn't test this issue with facebook.com or gmail.com as show password option is not available to check the character entered.
Able to reproduce the issue using the site paytm.com.

Attached is the screen cast for reference.

This is a Non-Regression issue as this behaviour is observed from M60 Chrome builds. 
Hence marking this as Untriaged for further updates from Dev.

Thanks.
848425-M60.mp4
1.4 MB View Download
Cc: ccameron@chromium.org
ccameron: Maybe related to your splitting up of RWHVM/C?
Labels: Needs-Bisect
Owner: ccameron@chromium.org
Status: Assigned (was: Untriaged)
Likely, needs a bisect though.
Labels: -Needs-Bisect
As per comment #3, able to reproduce the issue on Mac OS 10.13.3 on the latest Chrome builds, and the issue is observed from M-50 chrome builds.
Attached is the screen cast for reference.

Unable to provide the bisect information as the issue is observed from M-50 builds. Hence removing 'Needs-Bisect' label.

Thanks..


848425-M50.mp4
1.8 MB View Download
Oh, whoops, I missed #4.

This should be addressed in the context of Aura (anything else will be throw-away).
Labels: -Pri-2 Pri-3
Owner: ----
Status: Available (was: Assigned)
Labels: Hotlist-DesktopUIChecked Hotlist-DesktopUIValid
Mass UI Triage

Just to update: 
Still we are able to reproduce the issue on latest canary #72.0.3618.0 on  Mac(10.13.1, 10.13.4,10.14.2),  OS. 

Thank you.



Sign in to add a comment