The browsers work in mysterious ways.
That is, mostly they have certain reasons for behaving why they do, but because so many details are too sophisticated as to have been explicitly defined in some specification (…yet).
Recently, we came across a new problem that was surprisingly non-googleable.
Many of our interactive Web GUIs are based on Web Sockets for real-time updates. As is usual. Now, one live system showed a strange effect, because our Web Socket always broke down when the user clicked on a <a>...</a> link to download a file.
This was strange for multiple reasons, but it boiled down to:
- It happened under the current Firefox, but not under Chrome
- It happened not when the link had
target = "_blank"(i.e. the link was opening in a new window) - The Web Socket closed with the “going away” status code 1001, indicating no further error
And to boil it further down, the solution was to definitely include the download attribute for this particular <a> Element.
The web socket stayed open for both browsers in both of these cases:
<a href="..." target="_blank" rel="noopener noreferrer">
This leaves the Web Socket intact
</a>
<a href="..." download>
This also leaves the Web Socket intact
</a>
<a href="...">
This might close the Web Socket, or not, just as the browser feels today
</a>(For the rel="noopener noreferrer", see also here.)
The data from the href endpoint was served with the corresponding Content-Disposition and Content-Type HTTP headers. For Chrome, this is enough to identify that link as a download. Firefox was not so sure, it believes that you are actually “going away”.
Schneide Blog 