Yeah, the analysis here lends itself to a pretty simple heuristic: if the input for the password manager ends up on the page itself, the password manager is poorly designed. If the input ends up in a popup from the icon in your tool bar (which you can tell because it will draw a little arrow thingy that crosses past the edge of the web page), it is likely to be well-designed (in this respect).

All the icon on the webpage ought to do is indicate to the password manager that you'd like to use it, nothing else. You shouldn't be typing your master password there, you shouldn't see a list of sites there (perhaps you just see an option for the current web page, that's fine), etc.

1Password follows this rule and has a pretty good track record overall and I too use it. There are certainly password managers that don't follow this rule; don't use them.

What if browsers exposed the capabilities to locate the inputs, act upon user input, supply generated passwords, etc. in a sandboxed manner?

That’s how iOS Safari’s Password AutoFill works for both iCloud Keychain and third party password managers. Password managers can also supply a prebuilt list so that Safari handles everything, although custom widget handling user input is also allowed.

https://developer.apple.com/documentation/security/password_...

Edit: Of course it’s not limited to Safari, it works for in-app authentication flows too provided apps integrate it.

Or, even better, no passwords and just sensible pki

A browser-integrated password management API could make for a smoother transition to a future automated auth technology based on public keys, like WebAuthn

It's not just content scripts, I've seen vulnerabilities from information leaking(not necessarily creds) to authentication bugs.

Connecting the application that manages your secrets to the most exposed application on your PC is a bad idea.