It's unclear what you mean by "disables the secure input." A local attacker or JavaScript running in the page can trivially read the value of a password input field as it is typed in. 

https://www.chromium.org/Home/chromium-security/security-faq#TOC-What-about-unmasking-of-passwords-with-the-developer-tools-

Generally speaking, a keylogger can read whatever you type into any field, regardless of what type it is. Are you suggesting that MacOS somehow attempts to prevent the simplest form of attack by treating Password inputs specially?

A local attacker. By secure input I meant this https://developer.apple.com/library/content/technotes/tn2150/_index.html

I understand how keyloggers work and this is not about macOS treating Password inputs specially. I mean it is :), but it's about EnableSecureEventInput not being called in Chrome when a Text input is onfocus converted to Password input. I've checked this behaviour in Safari and Firefox and it works as expected there.

Digging from the source code, https://chromium.googlesource.com/chromium/src/+/56.0.2924.110/content/browser/renderer_host/render_widget_host_view_mac.mm#1683, in RenderWidgetHostViewMac::SetTextInputActive function EnablePasswordInput is called only when the input type is ui::TEXT_INPUT_TYPE_PASSWORD, but after the field was activated and callback for onfocus (which converts input Text to input Password) executed, the EnablePasswordInput isn't called anywhere or at least I don't see that it is.

I hope I made it clearer now. If not, let me know and I'll dig some more.

Fascinating. 

So MacOS *does* provide a means to treat a password input control differently, and WebKit does appear to try to use that mechanism: https://cs.chromium.org/search/?q=EnableSecureEventInput+package:%5Echromium$&type=cs.

Regardless of whether the OS mechanism is actually effective, the fact that WebKit ever bothers to call it suggests that WebKit/Blink should consider calling it in this scenario.

This is good to know about, but not a security bug in our threat model (requires local code execution), so I am removing the security restrictions.

Re comment 3, yes. It's effective to the extent that the Mac blocks events marked as being for a secure input field from being delivered to machine-wide app taps. It's not a hole re our security model, but as a Mac dev on Chrome, I'm actually rather surprised that we get this wrong. We really should be properly switching in and out of secure entry mode when focusing and blurring a password field.

Re #7: To be clear, the issue here is that when the field is entered, it's a plaintext field. JavaScript changes the field type after it obtains focus. This would be a boring corner case except that some real websites use this pattern because support for Placeholder attributes on password fields is not universal across older browsers. 

Presumably the fix is a simple check in the code that implements the field type switch to detect if the new or old type was Password and call the native API accordingly?

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

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