Match the Desktop Cert Display when WebKit gives no trust, but has a handshake (extremely rare and not a bug in WebKit).
Match the Desktop Cert Display when WebKit gives a trust, but no handshake at all (extremely rare and a bug in WebKit afaict).
TLDR:
Sometimes webkit gives a trust in the handshake, but none in didFailProvisionalNavigation.
Other times it gives a trust in didFailProvisionalNavigation, but none in the didReceiveChallenge handshake.
Both times, there is no trust at the END of the function call. Once the functions are called and returned from, webView.serverTrust becomes nil.
This is yet another edge case where the URL Bar can again show incorrectly. I'm not sure the reason why WebKit does this, but Chromium states that events come out of order and handles these edge cases the same way.
This pull request fixes #8703
Submitter Checklist:
[x] Unit Tests are updated to cover new or changed functionality
[x] User-facing strings use NSLocalizableString()
[x] New or updated UI has been tested across:
[x] Light & dark mode
[x] Different size classes (iPhone, landscape, iPad)
Summary of Changes
TLDR: Sometimes webkit gives a trust in the handshake, but none in didFailProvisionalNavigation. Other times it gives a trust in didFailProvisionalNavigation, but none in the didReceiveChallenge handshake. Both times, there is no trust at the END of the function call. Once the functions are called and returned from,
webView.serverTrustbecomes nil. This is yet another edge case where the URL Bar can again show incorrectly. I'm not sure the reason why WebKit does this, but Chromium states that events come out of order and handles these edge cases the same way.This pull request fixes #8703
Submitter Checklist:
NSLocalizableString()Reviewer Checklist:
QA/(Yes|No)bug/enhancement