I think the only way this can happen is zero-knowledge password proofs, i.e. browsers implement a mechanism by which password fields submit a proof that the user has the password, rather than submitting the password. This way the server can only verify the password if they've implemented the proof system correctly, and they can't leak the password because they've never had it.

The basic idea is, the server gives a unique nonce with the password form. The user enters their password. On form submit, the browser stretches the key space of the password using a slow hash, then uses the digest to generate an asymmetric key via a referentially transparent algorithm (no random salts). Then the browser prepends the URL (obtained from HTTPS) to the given nonce (to prevent man in the middle attacks). The browser then checks to see if it has seen this nonce before and displays an error if it has (to prevent replay attacks--this forces servers to generate new nonces, although the browser can't force them to verify that the nonce that is signed later is the same one they sent). Finally the browser uses the key to sign the nonce, and sends the signature to the server. The server uses the public key (which was generated in the same way and given to the server at sign-up) to verify that the user has the password.