dom/crypto - mozsearch

firefox-main/dom/crypto

	Name	Description	Size	Coverage
	CryptoBuffer.cpp		4364	81 %
	CryptoBuffer.h		1655	-
	CryptoKey.cpp		50179	87 %
	CryptoKey.h	The internal structure of keys is dictated by the need for cloning. We store everything besides the key data itself in a 32-bit bitmask, with the following structure (byte-aligned for simplicity, in order from least to most significant): Bits Usage 0 Extractable 1-7 [reserved] 8-15 KeyType 16-27 KeyUsage 28-31 [reserved] In the order of a hex value for a uint32_t 3 2 1 0 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \|~~~~~~~\| Usage \| Type \|~~~~~~~~~~~~~\|E\| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thus, internally, a key has the following fields: uint32_t - flags for extractable, usage, type KeyAlgorithm - the algorithm (which must serialize/deserialize itself) The actual keys (which the CryptoKey must serialize)	7659	100 %
	KeyAlgorithmProxy.cpp		8644	92 %
	KeyAlgorithmProxy.h		3965	96 %
	moz.build		819	-
<1%	test			-
	WebCryptoCommon.h		14514	92 %
	WebCryptoTask.cpp		141367	87 %
	WebCryptoTask.h	The execution of a WebCryptoTask happens in several phases 1. Constructor 2. BeforeCrypto 3. CalculateResult -> DoCrypto 4. AfterCrypto 5. Resolve or FailWithError 6. Cleanup If any of these steps produces an error (setting mEarlyRv), then subsequent steps will not proceed. If the constructor or BeforeCrypto sets mEarlyComplete to true, then we will skip step 3, saving the thread overhead. In general, the constructor should handle any parsing steps that require JS context, and otherwise just cache information for later steps to use. All steps besides step 3 occur on the main thread, so they should avoid blocking operations. Only step 3 is guarded to ensure that NSS has not been shutdown, so all NSS interactions should occur in DoCrypto Cleanup should execute regardless of what else happens.	8448	85 %

Revision control

Other Tools