[webkit-changes] [WebKit/WebKit] 8b9b48: Allow NSAttributedStrings to have CGColorRefs as a...

[Alex Christensen]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 8b9b488e6acc508fb6804b5a5be40eddb6359a9f
      https://github.com/WebKit/WebKit/commit/8b9b488e6acc508fb6804b5a5be40eddb6359a9f
  Author: Alex Christensen <achristensen at apple.com>
  Date:   2023-06-28 (Wed, 28 Jun 2023)

  Changed paths:
    M Source/WebCore/editing/cocoa/AttributedString.h
    M Source/WebCore/editing/cocoa/AttributedString.mm
    M Source/WebKit/Shared/Cocoa/WebCoreArgumentCodersCocoa.serialization.in

  Log Message:
  -----------
  Allow NSAttributedStrings to have CGColorRefs as attributes
https://bugs.webkit.org/show_bug.cgi?id=258650
rdar://109868642

Reviewed by Tim Horton.

Apparently PDFKit gives us some NSAttributedStrings when clicking on some PDFs
that have attributes of CGColorRef, which is distinct from UIColor and NSColor.
We need to keep the two types separate for the values to be interpreted correctly.

I manually verified that the PDF in the radar used to hit an assertion of an
unrecognized type in an attribute and now it doesn't.  I don't know what it is
about the PDF or how to make a good unit test for this.

* Source/WebCore/editing/cocoa/AttributedString.h:
* Source/WebCore/editing/cocoa/AttributedString.mm:
(WebCore::toNSObject):
(WebCore::extractValue):
* Source/WebKit/Shared/Cocoa/WebCoreArgumentCodersCocoa.serialization.in:

Canonical link: https://commits.webkit.org/265609@main