Bug 238651 - Translated applications cannot use remote methods with BOOL arguments
Summary: Translated applications cannot use remote methods with BOOL arguments
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Tim Horton
Keywords: InRadar
Depends on:
Reported: 2022-03-31 20:26 PDT by Tim Horton
Modified: 2022-04-01 09:40 PDT (History)
6 users (show)

See Also:

Patch (6.09 KB, patch)
2022-03-31 20:27 PDT, Tim Horton
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Horton 2022-03-31 20:26:34 PDT
Translated applications cannot use remote methods with BOOL arguments
Comment 1 Tim Horton 2022-03-31 20:27:14 PDT
Created attachment 456315 [details]
Comment 2 Tim Horton 2022-03-31 20:27:17 PDT
Comment 3 Tim Horton 2022-03-31 20:30:34 PDT
Going to have to mull how to test this
Comment 4 Geoffrey Garen 2022-03-31 20:34:39 PDT
Comment on attachment 456315 [details]

There must be a better way, but I don’t know immediately what it is.
Comment 5 EWS 2022-04-01 01:27:30 PDT
Committed r292209 (249112@main): <https://commits.webkit.org/249112@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 456315 [details].
Comment 6 Darin Adler 2022-04-01 09:40:03 PDT
Comment on attachment 456315 [details]

View in context: https://bugs.webkit.org/attachment.cgi?id=456315&action=review

I think someone should simplify this at some point. The string manipulation is unnecessarily roundabout.

> Source/WebKit/Shared/API/Cocoa/WKRemoteObjectCoder.mm:57
> +bool methodSignaturesAreCompatible(const String& wire, const String& local)

Not new to this patch: It seems strange to take const String& instead of const char* or NSString * for these arguments given how this function is used. Even if we really love WTF, we should use StringView here, not const String&.

As far as I can tell, all the strings passed to this function are created by calling the UTF8String method of an NSString, and then using that to create a String. Doing that is less efficient than just assigning an NSString to a String, because it allocates memory for a UTF-8 string, and although this is not important in this case, I think, it incorrectly handles non-ASCII characters, encoding them as UTF-8 and then treating them as Latin-1.

> Source/WebKit/Shared/API/Cocoa/WKRemoteObjectCoder.mm:68
> +        char localType = local[i];
> +        char wireType = wire[i];

This chops UChar down to char, which makes sense, I suppose, since what’s passed to this function a string that we know is all ASCII, but further calls into question why we are using WTF::String here at all.

> Source/WebKit/Shared/API/Cocoa/WKRemoteObjectCoder.mm:974
> +    String remoteMethodSignature = typeSignature.UTF8String;
> +    String localMethodSignature = [invocation methodSignature]._typeString.UTF8String;

Here’s one of those peculiar uses of UTF8String.

_WKRemoteObjectRegistry.mm has two others of those.