[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