Some PSM services need to be initialized on the main thread. Before this patch,
this was achieved by dispatching a synchronous task to the main thread in the
event that a different thread was attempting to acquire a given service for the
first time. However, with the upcoming removal of the nested event loop in the
XPCOM service instantiation code (see other patches in this bug), this can
cause a deadlock. This patch avoids the deadlock by removing the synchronous
dispatch and ensuring that these services get initialized on the main thread
relatively early, when PSM itself is initialized.
Differential Revision: https://phabricator.services.mozilla.com/D94145
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55444
CryptoTask is a helper class that makes it easier to implement code that runs on
a background thread and then notifies completion on the main thread (this is
useful for not blocking the main thread with long-running cryptography or I/O).
Before this patch, each CryptoTask would create a new thread each time it ran,
which was inefficient. This patch updates CryptoTask to use the stream transport
service (which is essentially a pool of threads for doing exactly these kinds of
things and notably is not to be confused with the socket transport service) to
run each task. Additionally, there were a few places in PSM where we
unnecessarily created new threads to perform similar tasks. These now use the
stream transport service as well.
Differential Revision: https://phabricator.services.mozilla.com/D33534
Before this patch, we exposed a few interfaces that revolved around mapping a
name to a specific PKCS#11 module, slot, or token. These APIs were all either
problematic and/or unnecessary. In theory there could be two tokens in different
modules with the same name, so nsIPK11TokenDB.findTokenByName wasn't guaranteed
to return what the consumer expected it to. In general, these APIs were used by
front-end code to go from a handle on the specific object in question to a
string identifier and then back to a handle on the object. This was unnecessary
- we can just retain the original handle.
MozReview-Commit-ID: IbqLbV4wceA
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
We're seeing a crash in tests from trying to release the promise in
this runnable from the background thread we create to run this
method. The only way I can see that happening is that the bg thread
loses the race with the main thread to drop its reference to the
runnable, causing it to call the destructor. Rather than calling the
helper that adds a reference to the runnable and then forgets it,
let's just forget it here.
MozReview-Commit-ID: LXpC8Kr2SBb
As of bug 1417680, the NSS shutdown tracking infrastructure is unnecessary (and
does nothing anyway). This series of changesets removes the remaining pieces in
a way that is hopefully easy to confirm is correct.
MozReview-Commit-ID: 8Y5wpsyNlGc
Since encryption can be somewhat CPU intensive, if we're encrypting
a large number of strings we want to be able to do so in a background
thread. This will be consumed by the profile migrators when importing
logins.
MozReview-Commit-ID: JoJGOgMzZ4u
Smart string classes like nsCString are safer to use than raw |char*| strings,
and are typically easier to deal with as well.
MozReview-Commit-ID: 18C293zWrJw
The Mozilla string classes don't require manual memory management and
automatically keep track of length, making them a safer choice than raw C
strings.
MozReview-Commit-ID: EwCiiP9EhDr
1. encrypt() and decrypt() are C++ only.
The only callers are in SecretDecoderRing.cpp, and binary add-ons aren't
supported anymore. So, there is no need for these methods to be defined in the
IDL, and they should be treated as private to the nsISecretDecoderRing
implementation.
2. nsISecretDecoderRingConfig has never been implemented.
The interface and implementation are currently just bloat. If there is a need
for specifying the window for prompts in the future, a better way can be devised
then.
MozReview-Commit-ID: 1wXCDTIBJA2
There are currently two ways of naming files containing the implementation of
interface nsIFoo:
1. nsFoo.(cpp|h) (previous convention)
2. Foo.(cpp|h) (new convention)
nsSDR.(cpp|h) matches neither of these. Renaming the files to follow convention
makes it easier to discover what the files implement, and increases codebase
consistency.
MozReview-Commit-ID: 3ThPxPouiie
serge-sans-paille