There are well worked out schemes which do achieve this e.g. Password Authenticated Key Exchange schemes (PAKE):
https://blog.cryptographyengineering.com/2018/10/19/lets-tal...
https://blog.cryptographyengineering.com/2018/10/19/lets-tal...
Which ends up with one of the parties writing this: https://palant.de/2018/10/25/should-your-next-web-based-logi...
The blog in the last link argues against the usefulness with the built-in browser implementation.
The arguments are pretty useful, even though I disagree with he's conclusions. I think the fact that if a compromised server has to revert from the secure browser-built-in password form, to a "regular login form" in order to learn your password, then that's a win for me
But what I'm suggesting is that whatever it is, it should be integrated with the browser's, so that when I am typing my password in a special password-input-field (which doesn't exist today), no javascript is allowed to read it's plain text, until the user manually unlocks it and the page is able to read it's H(pw || bFixedPub) or whatever protocol is apropiate.
That special password field, should appear outside the pageview, to prove that the page is not in control of it, or it's not allowed to phish it, only the browser has control, and when it's done, it sends to the page the resulting hash