My login for POST is over HTTPS. Therefore, I don't do anything to the provided password before submitting. And I don't see an issue there unless someone is watching your browser's developer console. (Tested the Google login. They also share the same approach.)
But I've received a concern asking "malicious user succeeds in session hijacking in someway will be able to access the end user credentials". Is this a valid argument? if so, how can I act?
Passing plain text passwords over HTTPS is absolutely fine. TLS makes sure it's not plaintext on the wire, so there is no issue. Client side hashing would do nothing to help here. The fact that you can get the password from the development console is expected and not an issue.
As for the concern about session hijacking, I don't get it at all. If an attacker that has hijacked a session could somehow get your password I would view that as a problem since it would allow an attacker to go from temporary access to permanent access. But sending your password untouched over HTTPS would on itself not lead to that. I think that either the person that told you this is misunderstanding something, or you misunderstood the concern. Is it perhaps related to some other wider issue?
Finally, a side note. You write that your "login for POST is over HTTPS". Are you using HTTPS just for the login? That is not enough. Your entire site - absolutely everything - needs to be over HTTPS. Just protecting the login endpoint makes you vulnerable to SSL-strip. If you use plain HTTP without TLS for parts of your website, you need to fix that.
Having the clear text on Developer Console is not an issue, it's part of how the browser works. TLS is designed to protect data between when it leaves your computer and reaches the end server. It's not to protect against hardware keyloggers, rubber-rose cryptanalysis, or developer consoles.
But I've received a concern asking "malicious user succeeds in session hijacking in someway will be able to access the end user credentials". Is this a valid argument? if so, how can I act?
If this is the concern, you must look somewhere else. The issue is not with TLS at all, the issue is at the application level, or database.
Do your application have any anti-XSS (cross site scripting) and anti-CSRF (Cross Site Request Forgery) protections in place? If not, an attacker may inject script on a client (XSS) or trick a client into accessing a crafted page while logged into your application (CSRF) and execute code as the user.
How are your application managing user input that is fed to databases? Is the application preventing SQL Injection? If not, an attacker may execute SQL on your database and leak data, specially passwords.
If the entire site is served over TLS, you don't have to care about that part. You need to make sure the application follows secure coding standards. That's what you can do. On the TLS side, it does not hurt to test the cyphers and modes enabled. SSL Labs have a good one.
You can avoid sending plaintext passwords over the wire, even if using TLS, but it won't be as easy to avoid sending something that is susceptible to a replay attack (i.e. a mangled password), even if that helps with protecting actual passwords.
But I've received a concern asking "malicious user succeeds in session hijacking in someway will be able to access the end user credentials". Is this a valid argument? if so, how can I act?
Session hijacking is an issue that is not directly affected by how he password is sent over the wire. A successful session hijacking attack lands the attacker on a valid authenticated session, as if they had just authenticated as a legitimate user, except they didn't. This does not reveal or leak information (including passwords) sent over the wire by the authenticated user (although the application itself could leak this information if it is poorly written).
It may be better if you compute some sort of hashed version of the password in the browser and pass that along to the server, that would eliminate the exposure of the plaintext password.
