Note, for example, that importKey/AES-KW/raw-key is identified as being supported (vs. blank).
Tested on:
iOS 9/Safari
Android/Chrome
Windows/Chrome
Windows/Firefox
Windows/Edge
Windows/IE 11
Improvements seen on:
iOS 9/Safari
Windows/Firefox
When an exception is thrown by the synchronous part of a Promise-returning function, that exception is (by design) not handled by any catch clauses associated with the call. Because of this, synchronous exceptions in cryptographic calls by the sample page can bubble up as script errors and cancel execution of the current and all remaining calls in a script block. As a result, compatibility information on some platforms (for example, Safari on iOS 9) is incomplete.
This change improves things by wrapping all calls to cryptographic functions in a Promise context so the existing catch clause executes and displays information about the relevant failure. Subsequent tests in the same script block are now able to run and display their own pass/fail information.
To minimize churn, this change wraps all cryptographic functions in a Promise context so each of the existing calls are (relatively) unchanged. (Platforms that do not support Promises do not benefit, but are no worse off.) An alternate implementation would be to introduce a Promise wrapper around each of the initial calls in a chain, but that causes more significant changes to the code and obfuscates the intent somewhat. Another alternate implementation would be to wrap each chain in a try/catch block, but that seems even more impactful/confusing. Configuration for each of the algorithms was moved to the top of the file because execution is now more asynchronous and it is possible for a configuration to be used before being initialized.
See commit description (below) for details.
Here is a live sample of the proposed changes: https://webcryptoexamples.azurewebsites.net/
Here is what Safari on iOS 9 looks like today without the change: https://webcryptoexamples.azurewebsites.net/iOS9-Safari-Before.png
And here's what it looks like with the proposed change: https://webcryptoexamples.azurewebsites.net/iOS9-Safari-After.png
Note, for example, that importKey/AES-KW/raw-key is identified as being supported (vs. blank).
Tested on:
Improvements seen on:
When an exception is thrown by the synchronous part of a Promise-returning function, that exception is (by design) not handled by any catch clauses associated with the call. Because of this, synchronous exceptions in cryptographic calls by the sample page can bubble up as script errors and cancel execution of the current and all remaining calls in a script block. As a result, compatibility information on some platforms (for example, Safari on iOS 9) is incomplete.
This change improves things by wrapping all calls to cryptographic functions in a Promise context so the existing catch clause executes and displays information about the relevant failure. Subsequent tests in the same script block are now able to run and display their own pass/fail information.
To minimize churn, this change wraps all cryptographic functions in a Promise context so each of the existing calls are (relatively) unchanged. (Platforms that do not support Promises do not benefit, but are no worse off.) An alternate implementation would be to introduce a Promise wrapper around each of the initial calls in a chain, but that causes more significant changes to the code and obfuscates the intent somewhat. Another alternate implementation would be to wrap each chain in a try/catch block, but that seems even more impactful/confusing. Configuration for each of the algorithms was moved to the top of the file because execution is now more asynchronous and it is possible for a configuration to be used before being initialized.