I know that once a password is on a server it is hashed and salted. But when it was transferred over the internet it was stored in plain text, right? And also when it is in the memory of the server before it's been hashed.
I think the short answer is that TLS provides encryption in transit over the internet, but the password needs to exist in plaintext on both the browser and the server, and usually little is done to protect or obfuscate it there.
Your browser will establish an encrypted TLS session with the server; which means the wifi access point, your home router, routers on the internet, etc will see the password go by encrypted.
The TLS session will be decrypted at the server and it will have the plaintext password in memory. Since it needs the plaintext to do the hashing, this cannot be avoided. Best practice is to have the password in memory for as little time as possible; ie hash it, check it, and then free that memory (zeroing it out first if you're in a programming language that lets you do that); basically don't keep the password around in server memory longer than you need to.
Mike Ounsworth's answer explains the standard way that passwords are sent from a client to a server - i.e. the client has the password in plaintext, the client sends the password 'in plaintext' through an SSL/TLS encrypted tunnel, then the server receives the password in plainttext. See more on this at Is it ok to send plain-text password over HTTPS?.
Protocols like PAKE and SRP enable a client to prove to a server that it has knowledge of the password, without the client sending the password (or password-equivalent data) over the wire. See Alternatives for sending plaintext password while login for more info.