Bug 202753 – [Cocoa] IPC::decode should gracefully handle a nil allowed class

• Component: New Bugs
• Status: RESOLVED FIXED

[Andy Estes]

[Cocoa] IPC::decode should gracefully handle a nil allowed class

[Andy Estes]

Created attachment 380537 [details]
Patch

[Geoffrey Garen]

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?

[Timothy Hatcher]

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.

[Andy Estes]

(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.

[Andy Estes]

(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.

[WebKit Commit Bot]

Comment on attachment 380537 [details]
Patch

Clearing flags on attachment: 380537

Committed r250934: <https://trac.webkit.org/changeset/250934>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Radar WebKit Bug Importer]

<rdar://problem/56130523>