I'm not sure bug 1634065 would have changed this one way or another. It seems like we have a preexisting issue where if `EnsureNSSInitializedChromeOrContent()` has never been called, it could think it needs to dispatch to the main thread, even if NSS has already been initialized (which causes a problem if the currently running code is holding a lock that the main thread is waiting on). My guess is if we replaced ` nsCOMPtr<nsISupports> psm = do_GetService(PSM_COMPONENT_CONTRACTID, &rv);` with `EnsureNSSInitializedChromeOrContent()` at [0], this wouldn't happen.
I'm not sure bug 1634065 would have changed this one way or another. It seems like we have a preexisting issue where if `EnsureNSSIniti alizedChromeOrC ontent( )` has never been called, it could think it needs to dispatch to the main thread, even if NSS has already been initialized (which causes a problem if the currently running code is holding a lock that the main thread is waiting on). My guess is if we replaced ` nsCOMPtr< nsISupports> psm = do_GetService( PSM_COMPONENT_ CONTRACTID, &rv);` with `EnsureNSSIniti alizedChromeOrC ontent( )` at [0], this wouldn't happen.
[0] https:/ /searchfox. org/mozilla- central/ rev/6bb59b783b1 93f06d6744c5cca ac69a992e9ee7b/ netwerk/ base/nsNetUtil. cpp#2718