[Cocoa] IPC::decode should gracefully handle a nil allowed class
Created attachment 380537 [details] Patch
Comment on attachment 380537 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=380537&action=review r=me > Source/WebKit/ChangeLog:20 > + rdar://problem/55839467 was resolved by fixing the build misconfiguration, but this patch > + improves IPC::decode so that a nil allowed class results in a message decoding failure > + rather than a maybe-caught NSException. > + What do message decoding failures do at runtime? Would this error we experienced still be obvious, or would it become more subtle?
Comment on attachment 380537 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=380537&action=review >> Source/WebKit/ChangeLog:20 >> + > > What do message decoding failures do at runtime? Would this error we experienced still be obvious, or would it become more subtle? When the allowedClasses array is empty, we assert in debug builds and always return nil for the decoded object. So it would depend on the caller to handle that.
(In reply to Geoffrey Garen from comment #2) > Comment on attachment 380537 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=380537&action=review > > r=me > > > Source/WebKit/ChangeLog:20 > > + rdar://problem/55839467 was resolved by fixing the build misconfiguration, but this patch > > + improves IPC::decode so that a nil allowed class results in a message decoding failure > > + rather than a maybe-caught NSException. > > + > > What do message decoding failures do at runtime? Would this error we > experienced still be obvious, or would it become more subtle? The new failure mode is that a call to sendSync() with an infinite timeout now returns false when decoding fails in the remote process (rather than hanging). For cases like rdar://problem/55839467, returning false causes PaymentCoordinator to throw a JavaScript exception telling the webpage that the payment UI could not be presented. We also have a LOG_ERROR (but not a RELEASE_LOG_ERROR) for when secure coding-style decoding fails.
(In reply to Andy Estes from comment #4) > returning false causes > PaymentCoordinator to throw a JavaScript exception telling the webpage that > the payment UI could not be presented. We also have a LOG_ERROR (but not a > RELEASE_LOG_ERROR) for when secure coding-style decoding fails. ... which I think is at least as obvious a symptom as a hang, in that the Apple Pay UI does not appear in response to button activation in either case.
Comment on attachment 380537 [details] Patch Clearing flags on attachment: 380537 Committed r250934: <https://trac.webkit.org/changeset/250934>
All reviewed patches have been landed. Closing bug.
<rdar://problem/56130523>