URL encoding for whole string instead of only Password

After updating Chrome and Edge browsers we noticed winscp will not connect while launching from browser and when proxy settings in place.

Current version of Chrome is: 130.0.6723.59

Earlier we used to launch with below URL using href in <a> tag, this is not working any more

It seems that Chrome now mis-encodes the semicolons to %3B, instead of keeping them intact.
Would you please report it to them? Nothing we can do about it.
Post a link here, if you do.

It looks like Chrome is encoding the characters. Is it not WinSCP job to handle the encryption like password that you already do?

https://issues.chromium.org/issues/374802773

Thanks for reporting it. If you need any help with providing them with problem details, let me know.

I'm not sure I understand your note about WinSCP's job.

Looks like both Edge and Chrome have same issue.
What I meant is URL is encoded when SFTP is encoded. That’s the reason why semicolon is converted to %3B. Why can’t WinSCP decode the whole URL and use required parameters such as username, password, proxy, etc..

Edge is built on Chromium.
I'm not sure what you mean by "when SFTP is encoded".
Anyway, if you mean that WinSCP should be able to decode the %3B, it cannot. Because the URL that it gets form Chrome is valid:
It means to that username is username;x-proxymethod=3;x-proxyhost=proxyhost;x-proxyport=1234;x-proxyusername=proxy;x-proxypassword=xxxxxxxxxxxxx

---

Anyway, it looks like the change in Chromium was deliberate:
https://issues.chromium.org/issues/375228139
So they probably won't change/undo it. They claim some "URL standards". I'm not sure what standards do they mean. According to RFC 3986, semicolons are reserved symbols and should be kept intact.
According to linked Google's document, viable workaround is to drop the // from the URL. Then Chrome does not try to understand the URL (according to its own rules) and passes it intact to WinSCP. Would it work for you?
I have documented it:
https://winscp.net/eng/docs/session_url#semicolons

Working fine on Edge V130.0.2849.56, might be they fixed it.

Looks like dropping // is working fine on Chrome.

Thanks for your feedback.