A few false turns, but I found out where the BAD_CERT error is showing up. It's obscured a little due to how the SocketTransport defers some of the connection and handshaking, but we end up seeing an error when we first attempt to Read from the connection. A bunch of errors are caught and handled at this point: https://searchfox.org/comm-central/source/mailnews/imap/src/nsImapProtocol.cpp#4731 Most of these boil down to invoking [nsIMsgMailSession.alertUser()[(https://searchfox.org/comm-central/source/mailnews/base/src/nsMsgMailSession.cpp#173), passing in the named error and the IMAP URL that was being run. The `alertUser()` implementation calls `onAlert()` on any `nsIMsgUserFeedbackListener` registered to the session, and tries to pop up a prompt dialog for the associated `nsIMsgWindow`. As I understand it, previously the low-level SSL/TLS code would just directly invoke a `nsIBadCertListener2`, and the IMAP code wouldn't have to worry about it. Now, we'll need to: - catch the bad cert error - propagate it up to the GUI, which probably means defining a new message type (as for `imapConnectionRefusedError`, `imapUnknownHostError` et al) - show a dialog box to explain about the bad cert and potentially offer an option to bypass it. (maybe reusing whatever UI `nsIBadCertListener2` used). There's still one disconnect I don't quite grasp: the current (non-bad cert) error handling happens via the `onStopRequest()` in the `nsIRequestObserver`/`nsIStreamListener` for the URL being run. Particularly for the wizard, this seems pretty vital. But I haven't figured out how the other failures in the read code are being propagated back out to the `onStopRequest()` handler. Presumably I now need to figure out how to get the BAD_CERT error code showing up in ` onStopRequest()`, right? I can't yet see how _any_ of the other read errors are propogated out to `onStopRequest()`. It's possible they aren't, and that a generic error is generated when the IMAP connection is killed (it's killed as part of the read error handling)... (and then we likely need to do the same thing for other protocols - SMTP? POP3? what else?)
Bug 1590473 Comment 23 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
A few false turns, but I found out where the BAD_CERT error is showing up. It's obscured a little due to how the SocketTransport defers some of the connection and handshaking, but we end up seeing an error when we first attempt to Read from the connection. A bunch of read errors are caught and handled at this point: https://searchfox.org/comm-central/source/mailnews/imap/src/nsImapProtocol.cpp#4731 Most of these boil down to invoking [nsIMsgMailSession.alertUser()[(https://searchfox.org/comm-central/source/mailnews/base/src/nsMsgMailSession.cpp#173), passing in the named error and the IMAP URL that was being run. The `alertUser()` implementation calls `onAlert()` on any `nsIMsgUserFeedbackListener` registered to the session, and tries to pop up a prompt dialog for the associated `nsIMsgWindow`. As I understand it, previously the low-level SSL/TLS code would just directly invoke a `nsIBadCertListener2`, and the IMAP code wouldn't have to worry about it. Now, we'll need to: - catch the bad cert error - propagate it up to the GUI, which probably means defining a new message type (as for `imapConnectionRefusedError`, `imapUnknownHostError` et al) - show a dialog box to explain about the bad cert and potentially offer an option to bypass it. (maybe reusing whatever UI `nsIBadCertListener2` used). There's still one disconnect I don't quite grasp: the current (non-bad cert) error handling happens via the `onStopRequest()` in the `nsIRequestObserver`/`nsIStreamListener` for the URL being run. Particularly for the wizard, this seems pretty vital. But I haven't figured out how the other failures in the read code are being propagated back out to the `onStopRequest()` handler. Presumably I now need to figure out how to get the BAD_CERT error code showing up in ` onStopRequest()`, right? I can't yet see how _any_ of the other read errors are propogated out to `onStopRequest()`. It's possible they aren't, and that a generic error is generated when the IMAP connection is killed (it's killed as part of the read error handling)... (and then we likely need to do the same thing for other protocols - SMTP? POP3? what else?)
A few false turns, but I found out where the BAD_CERT error is showing up. It's obscured a little due to how the SocketTransport defers some of the connection and handshaking, but we end up seeing an error when we first attempt to Read from the connection. A bunch of read errors are caught and handled at this point: https://searchfox.org/comm-central/source/mailnews/imap/src/nsImapProtocol.cpp#4731 Most of these boil down to invoking [nsIMsgMailSession.alertUser()](https://searchfox.org/comm-central/source/mailnews/base/src/nsMsgMailSession.cpp#173), passing in the named error and the IMAP URL that was being run. The `alertUser()` implementation calls `onAlert()` on any `nsIMsgUserFeedbackListener` registered to the session, and tries to pop up a prompt dialog for the associated `nsIMsgWindow`. As I understand it, previously the low-level SSL/TLS code would just directly invoke a `nsIBadCertListener2`, and the IMAP code wouldn't have to worry about it. Now, we'll need to: - catch the bad cert error - propagate it up to the GUI, which probably means defining a new message type (as for `imapConnectionRefusedError`, `imapUnknownHostError` et al) - show a dialog box to explain about the bad cert and potentially offer an option to bypass it. (maybe reusing whatever UI `nsIBadCertListener2` used). There's still one disconnect I don't quite grasp: the current (non-bad cert) error handling happens via the `onStopRequest()` in the `nsIRequestObserver`/`nsIStreamListener` for the URL being run. Particularly for the wizard, this seems pretty vital. But I haven't figured out how the other failures in the read code are being propagated back out to the `onStopRequest()` handler. Presumably I now need to figure out how to get the BAD_CERT error code showing up in ` onStopRequest()`, right? I can't yet see how _any_ of the other read errors are propogated out to `onStopRequest()`. It's possible they aren't, and that a generic error is generated when the IMAP connection is killed (it's killed as part of the read error handling)... (and then we likely need to do the same thing for other protocols - SMTP? POP3? what else?)