Thanks for your report - I can't reproduce this locally, either with 70.0.3538.67 or with 72.0.3584.0 on 10.13.6. I also can't reproduce it on 71.0.3569.0.

I'm trying it on this "page": data:text/html,<input type="password">

1) Can you try it with that "page"?
2) Is there a specific page you see this problem on?

1) I tried this with that "page" and I've still got the same issue.
2) I've never used a website where I haven't had this issue. I can name facebook.com and accounts.google.com/ServiceLogin as prominent examples.

Is this maybe a macOS-build exclusive issue?

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I've tested this on 10.14.0 as well now with no success.

Grasping at straws here: what happens if you try it in a new profile?

I tried it in a new profile, still the same issue.

I've attached a screen recording where I demonstrate this issue with the macOS on-screen keyboard. 

What else can I try out?
(by the way thank you taking my issue seriously)

Deleted: Bildschirmaufnahme 2018-10-25 um 21.20.26.mov 2.8 MB

	Bildschirmaufnahme 2018-10-25 um 21.20.26.mov 2.8 MB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Unable to reproduce the issue on mac 10.14 and 10.13.6 using chrome reported version #69.0.3497.100, latest stable #70.0.3538.77 and latest canary #72.0.3591.0.
Attached a screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
1. Navigated to https://accounts.google.com/signin/chrome/sync/identifier?ssp=1&continue=https%3A%2F%2Fwww.google.co.in%2F&flowName=GlifDesktopChromeSync
2. Tried using the circumflex (^) as a single sign in the username and password field.
3. Observed that circumflex sign is accepted as a possible input sign for passwords after entered through the keyboard but observed that on inputting the circumflex sign using a macOS on-screen keyboard neither accept for user name nor password.

reporter@ - Could you please let us know if the issue reproduce only with macOS on-screen keyboard? Also could you please check the issue on latest canary #72.0.3591.0 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not.

Thanks...!!

Deleted: 895434.mp4 1.0 MB

	895434.mp4 1.0 MB View Download

Adding some more folks from Blink, even though I am not sure at which layer this is processed. Maybe it helps routing the bug to the right people.

I notice two things in the video:

1) The keyboard layout in the on-screen keyboard is unfamiliar to me - I don't know of a layout that has circumflex and degree sign at the top-left like that.
2) The circumflex key is highlighted as a modifier key in the onscreen keyboard, and in the video it appears to trigger a kind of composition mode - notice how in the plaintext field the ^ is underlined, which usually means "beginning composition" in macOS.

Reporter:

What is your keyboard layout set to (System > Keyboard > Input Sources)?

@krajshree no this issue reproduces for me with the on-screen keyboard AND the normal hardware macbook keyboard. I've tried on version 72.0.3598.0 canary (64-Bit) with a brand new profile and still got this issue.

@ellyjo... My keyboard is set to "German". The layout of the on-screen keyboard looks exactly like the layout of my hardware keyboard as it's produced by Apple (for example with the upper-left circumflex/degree key etc.).

But you are right, I've noticed how the "^" and "´" key in the on-screen keyboard is highlighted with a orange box. Could this be an indicator for something? 

Deleted: Bildschirmfoto 2018-11-01 um 20.41.14.png 61.3 KB

	Bildschirmfoto 2018-11-01 um 20.41.14.png 61.3 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

#11: The orange indicator means that the key is a "dead key" in that layout - i.e., it will not type a character on its own, but will let you type other characters and will then combine them into some other character that the keyboard can't normally express.

For example, if I switch to the "US International" layout, I see an orange ring around the key labelled "` / ~" at the top left, meaning it is a dead key. If I press that key, rather than directly inserting a '`', it inserts a '`' and highlights it in yellow, meaning "waiting for rest of character".  I can then hit space to insert a literal '`', or I can type (e.g.) 'a' to insert an `à`.

i.e.:
Type ` -> waits for more characters
Type ` -> type space -> inserts `
Type ` -> type a -> inserts à

So, your keyboard layout has a dead key on the circumflex character - that explains the orange outline on the onscreen keyboard, and the compose effect when you're typing in the normal text field.

Can you check whether you can type '^' in password fields in Safari?

Thank you for the explanation!

Yes, Safari (version 12.0) on the same device/macOS/keyboard layout allows me to type '^' into a password field.

Alright, so this is probably a Blink>Input bug indeed around password fields.

Over to... thakis@?

That's effectively the same as WontFixing, so if that's what you want to do, then do that :-P

It does not seem related to Chrome's functionality around saving passwords, so removing that component.

Mac triage: over to avi@! looks like a good ol' dead key handling bug :)

I haven't done any keyboard work.

Did we used to switch keyboard layouts for password fields and stop doing so?

+peeps who've done some input work

Two very interesting versions of this are going on.

1. The Google login page seems to be magical. If the eye is crossed out on the right side, Safari turns the dead-key press for ^ into a lone ^, while Chrome ignores it.
2. For a normal password field like https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_input_type_password, Safari is *honoring* the dead-key press, showing an _underlined bullet_ and doing full IME while Chrome again is ignoring it.

This is going to require a bit more input experience than I have. Dave? Erik?

This doesn't seem like a blink bug but a piece of code that avoids enabling IMEs for password inputs.

If the following line:
https://cs.chromium.org/chromium/src/content/browser/renderer_host/render_widget_host_view_cocoa.mm?l=1650&rcl=b5888d39c8a91df48d327de6c059c2b6504e80e5

is removed then it works correctly.

Ooh, thanks Dave. I wonder why we avoided IMEs in password fields?

We inherit the behavior from WebKit.

https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/html/PasswordInputType.cpp#L65
bool PasswordInputType::shouldUseInputMethod() const
{
    // Input methods are disabled for the password field because otherwise
    // anyone can access the underlying password and display it in clear text.
    return false;
}

But how does Safari do it then?

> But how does Safari do it then?

Ah, maybe "disable IME" implementation is different. So this is not identical to Issue 78048.

I remember text input of WebKit and Blink are different on macOS. For example, "text substitution" does not work in Blink but work in WebKit.  Issue 42434

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3ec55a05f5fb5252442fee0c12d9e732bc7aeae2

commit 3ec55a05f5fb5252442fee0c12d9e732bc7aeae2
Author: Elly Fong-Jones <ellyjones@chromium.org>
Date: Wed Nov 28 17:03:42 2018

mac content: use IMEs for password inputs

Not using an IME here makes certain keyboard layouts very difficult to use.

Bug: 895434
Change-Id: I76e6121ca6512c8804fdb4afd2bceba10160bef0
Reviewed-on: https://chromium-review.googlesource.com/c/1351151
Commit-Queue: Elly Fong-Jones <ellyjones@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#611739}
[modify] https://crrev.com/3ec55a05f5fb5252442fee0c12d9e732bc7aeae2/content/browser/renderer_host/render_widget_host_view_cocoa.mm