I suspect a mismatch in the proxy settings of the different browsers.
If IE's proxy settings were configured manually, these settings will have to be repeated in your other browsers. If they are configured automatically, hopefully all browsers should be receiving the same settings -- any discrepancy there may cause these failures.
The proxy auto-configuration script (PAC) in your environment could use some features only working well in IE. Is a PAC script downloaded to your browser (result of "Detecting Proxy Settings...") or visible in your browser's proxy settings ?
In recent versions of chrome, you can view the current PROXY settings by visiting URL: chrome://net-internals/#proxy . These settings hopefully match those of IE . Proxy settings in Firefox can be viewed or changed by following the instructions in https://support.mozilla.org/en-US/kb/advanced-panel-settings-in-firefox (look for "Automatic proxy configuration URL" in that page). If you know with certainty that your work environment's proxy settings are "configured automatically", set all your browsers as such.
If you come to the a point where all browsers proxy settings are the same and a PAC file is involved. I.e. it is possible the file obtained with wpad may work in one browser, but not in another, you'll have to investigate deeper.
The first pointer in the list below can help one download the proxy script file in IE. If the PAC file URL is served by a webserver (i.e. the wpad file is a http(s):// url), I would recommend first checking if downloaded versions of the same file from IE, Chrome, and Firefox are all exactly the same. This webserver might change its response based on the requesting user-agent. One has to inspect the version for the browser that's not working if they are different.
Once the script that Chrome or Firefox would use is obtained, one must inspect it. That's the harder part. One has to simulate what the script would do if it were to be supplied slack.com's websocket URL and host. Maybe this can be done by visual inspection and deduction, but if the script is very complicated, a tool may be used (see the debugging link in the list).
One thing to watch out for are the presence of functions not supported by the particular browser. I suspect errors encountered in those scripts are not well reported to the user, and behaviour in error cases might be ill-defined.
At this point I can only provide pointers.
and some background info: