[webkit-changes] [WebKit/WebKit] 0ba9e6: WebPage_LoadRequest IPC fails decoding in PingDuoD...
Chris Dumez
noreply at github.com
Mon Jun 26 15:33:34 PDT 2023
Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 0ba9e6c4473fcc7d78aaa785794cbd884e61a094
https://github.com/WebKit/WebKit/commit/0ba9e6c4473fcc7d78aaa785794cbd884e61a094
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-06-26 (Mon, 26 Jun 2023)
Changed paths:
M Source/WebKit/Shared/Cocoa/ArgumentCodersCocoa.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/IPCTestingAPI.mm
Log Message:
-----------
WebPage_LoadRequest IPC fails decoding in PingDuoDuo app
https://bugs.webkit.org/show_bug.cgi?id=258486
rdar://111161160
Reviewed by Tim Horton.
WebPage_LoadRequest IPC was failing decoding in PingDuoDuo app.
The issue was due to getting a WKSecureCodingURLWrapper instead
of a NSURL when decoding the baseURL of a NSURL.
I am not sure how we ended up in this situation but I made the
bug go away by simplifying the code. The coder used to encode
the URL in two parts:
1. The baseURL
2. The bytes from the URL's relative string
Then it would decode the URL in 2 parts:
1. The baseURL
2. The bytes from the URL's relative string
It would then call CFURLCreateAbsoluteURLWithBytes() with those
2 parts, which would result in an *absolute* URL. The information
about baseURL / relative string would be lost.
As a result, I have decided to simply encode the URL in one part,
the absolute URL bytes. The decoding results ends up being the
same (an absolute URL). It simplifies both coding and decoding
and makes the bug go away since it was about decoding baseURLs.
* Source/WebKit/Shared/Cocoa/ArgumentCodersCocoa.mm:
(-[WKSecureCodingURLWrapper encodeWithCoder:]):
(-[WKSecureCodingURLWrapper initWithCoder:]):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/IPCTestingAPI.mm:
Canonical link: https://commits.webkit.org/265529@main
More information about the webkit-changes
mailing list