This should avoid crashes in Final Fantasy XIV launcher when pressing login button after entering credentials.
The crash happens in xul.dll because ccref_decr() is called from an unrelated thread (thread pool thread used in wininet) while Gecko code expects to find thread local sCollectorData variable in NS_CycleCollectorSuspect3().
The POST request is canceled from Gecko / mshtml resulting in urlmon.HttpProtocol_Terminate() which results in wininet.InternetCloseHandle for request. That eventually results in INTERNEL_HANDLE_CLOSING callback from wininet which is sent from a threadpool thread. The handling in urlmon releases BINDINFO data stored in Protocol (with urlmon.ReleaseBindInfo). For POST requests that currently contains pUnkForRelease which is released inside ole32.ReleaseStgMedium. That is the last reference to mshtml's BindStatusCallback and destroying it results in xul ccref_decr call from a random thread.
I checked that: - wininet behaves the same as Windows in critical aspect here: INTERNEL_HANDLE_CLOSING is sent from another thread on Windows as well when the handle is closed during active request processing. There is the difference, Windows aborts the requests, delivers appropriate status code and calls INTERNEL_HANDLE_CLOSING much sooner, but still on a different thread and after InternetCloseHandle exited; - urlmon behaves the same in principle: I instrumented tests with setting pUnkForRelease in test's BindInfo, and if terminating a just started request that Release is called on another thread and after return from _Terminate (even if much sooner than with Wine where wininet requests are currently not aborted).
So that looks like mshtml + Gecko issue to me and avoiding referencing BindStatusCallback from BINDATA avoids it (as the last reference is never freed from random wininet threadpool threads). The copied data are freed by ole32.ReleaseStgMedium() now when pUnkForRelease is NULL.