2001-10-30 23:52:01 +00:00
|
|
|
/* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
|
2012-05-31 09:33:35 +00:00
|
|
|
/* This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
|
2001-10-30 23:52:01 +00:00
|
|
|
|
|
|
|
|
#ifndef _NSCERTPICKER_H_
|
|
|
|
|
#define _NSCERTPICKER_H_
|
|
|
|
|
|
|
|
|
|
#include "nsIUserCertPicker.h"
|
bug 1215690 - remove nsPSMUITracker r=Cykesiopka r=mgoodwin
nsPSMUITracker was problematic. Apparently it was originally intended to prevent
NSS shutdown while NSS-related UI operations were going on (such as choosing a
client certificate). However, when nsNSSComponent would receive the event that
told it to shutdown NSS, it would attempt to call
mShutdownObjectList->evaporateAllNSSResources(), which would call
mActivityState.restrictActivityToCurrentThread(), which failed if such a UI
operation was in progress. This actually prevented the important part of
evaporateAllNSSResources, which is the releasing of all NSS objects in use by
PSM objects. Importantly, nsNSSComponent didn't check for or handle this failure
and proceeded to call NSS_Shutdown(), leaving PSM in an inconsistent state where
it thought it was okay to keep using the NSS objects it had when in fact it
wasn't.
In any case, nsPSMUITracker isn't really necessary as long as we have the
nsNSSShutDownPreventionLock mechanism, which mostly works and is what we should
use instead (or not at all, if no such lock is needed for the operation being
performed (for example, if no NSS functions are being called)).
2015-10-16 21:31:57 +00:00
|
|
|
#include "nsNSSShutDown.h"
|
2001-10-30 23:52:01 +00:00
|
|
|
|
|
|
|
|
#define NS_CERT_PICKER_CID \
|
|
|
|
|
{ 0x735959a1, 0xaf01, 0x447e, { 0xb0, 0x2d, 0x56, 0xe9, 0x68, 0xfa, 0x52, 0xb4 } }
|
|
|
|
|
|
|
|
|
|
class nsCertPicker : public nsIUserCertPicker
|
bug 1215690 - remove nsPSMUITracker r=Cykesiopka r=mgoodwin
nsPSMUITracker was problematic. Apparently it was originally intended to prevent
NSS shutdown while NSS-related UI operations were going on (such as choosing a
client certificate). However, when nsNSSComponent would receive the event that
told it to shutdown NSS, it would attempt to call
mShutdownObjectList->evaporateAllNSSResources(), which would call
mActivityState.restrictActivityToCurrentThread(), which failed if such a UI
operation was in progress. This actually prevented the important part of
evaporateAllNSSResources, which is the releasing of all NSS objects in use by
PSM objects. Importantly, nsNSSComponent didn't check for or handle this failure
and proceeded to call NSS_Shutdown(), leaving PSM in an inconsistent state where
it thought it was okay to keep using the NSS objects it had when in fact it
wasn't.
In any case, nsPSMUITracker isn't really necessary as long as we have the
nsNSSShutDownPreventionLock mechanism, which mostly works and is what we should
use instead (or not at all, if no such lock is needed for the operation being
performed (for example, if no NSS functions are being called)).
2015-10-16 21:31:57 +00:00
|
|
|
, public nsNSSShutDownObject
|
2001-10-30 23:52:01 +00:00
|
|
|
{
|
|
|
|
|
public:
|
|
|
|
|
NS_DECL_ISUPPORTS
|
|
|
|
|
NS_DECL_NSIUSERCERTPICKER
|
|
|
|
|
|
|
|
|
|
nsCertPicker();
|
2014-06-23 22:40:03 +00:00
|
|
|
|
bug 1215690 - remove nsPSMUITracker r=Cykesiopka r=mgoodwin
nsPSMUITracker was problematic. Apparently it was originally intended to prevent
NSS shutdown while NSS-related UI operations were going on (such as choosing a
client certificate). However, when nsNSSComponent would receive the event that
told it to shutdown NSS, it would attempt to call
mShutdownObjectList->evaporateAllNSSResources(), which would call
mActivityState.restrictActivityToCurrentThread(), which failed if such a UI
operation was in progress. This actually prevented the important part of
evaporateAllNSSResources, which is the releasing of all NSS objects in use by
PSM objects. Importantly, nsNSSComponent didn't check for or handle this failure
and proceeded to call NSS_Shutdown(), leaving PSM in an inconsistent state where
it thought it was okay to keep using the NSS objects it had when in fact it
wasn't.
In any case, nsPSMUITracker isn't really necessary as long as we have the
nsNSSShutDownPreventionLock mechanism, which mostly works and is what we should
use instead (or not at all, if no such lock is needed for the operation being
performed (for example, if no NSS functions are being called)).
2015-10-16 21:31:57 +00:00
|
|
|
// Nothing to actually release.
|
|
|
|
|
virtual void virtualDestroyNSSReference() override {}
|
|
|
|
|
|
2014-06-23 22:40:03 +00:00
|
|
|
protected:
|
2001-10-30 23:52:01 +00:00
|
|
|
virtual ~nsCertPicker();
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#endif //_NSCERTPICKER_H_
|