Thanks for the additional information. I had forgotten all about that about:config override setting because it’s not practical to expect most users to reconfigure their browser in that way. Given the scenarios in this topic though, it’s a potentially viable workaround.
However, be aware that enabling this setting will expose your local network to external port scanners and also increases the risk of malicious connections to local websockets which rely upon random port numbers for protection against compromise from external networks (KeePassRPC is not affected by this but see the previous security vulnerability for a good example of how multiple vulnerabilities in a local WebSocket server could be chained with the ability for an attacker to rapidly attempt connecting to every local port).
Thus, if you decide to keep this setting false for the purposes of a specific development project, I’d recommend setting yourself a reminder to change it back to the default when the project is complete.
We already check if we can connect with HTTP before trying the WebSocket connection but because different operating systems and security software can alter the type of connection failure that Firefox sees, we must also make regular attempts to the WebSocket independently of the result of that test. These environment differences are likely to explain some of the different behaviours we’re all seeing.
I also think there are two separate issues confusing the matter here:
- Firefox (and maybe other browsers) forces an increasing delay to failed WebSocket connections and it appears to consider all ports on localhost as equivalent for that calculation
- Firefox (and maybe other browsers) don’t allow more than one concurrent attempt to a WebSocket on localhost
Focussing on the latter for a moment, I think the problem would be at least minimised if we could ensure that Firefox aborts the attempt to connect to KeePassRPC after a shorter period of time, perhaps user configurable if this is something that can occasionally take many seconds on some slower machines.
We have a 750ms timeout for the HTTP requests every 2 seconds but I don’t think the WebExtensions or Web APIs offer a way to do this for WebSockets. Feel free to take a look to confirm if you have time. However, bear in mind that the upcoming Chrome manifest v3 migration (likely in 2022) might force us to make wider changes to the way we connect to KeePassRPC anyway so this probably isn’t something we should spend a lot of time on until then.