rdar://problem/21929532 Safari AutoFill is failing to fill some contact information. The reason appears to be that an object graph being sent via WKRemoteObjectRegistry includes NSMutableString instances, and after <http://trac.webkit.org/changeset/184026> those aren’t being decoded correctly: that change applies custom encoding for NSString and its subclasses, but only the corresponding custom decoding for NSString itself. Patch forthcoming.
Created attachment 257435 [details] Use custom string coding for NSString and NSMutableString only
Fixed in <http://trac.webkit.org/r187288>.
Given that NSString is a class cluster, allocating a string with methods of NSString can create an object of a class derived from NSString, not NSString itself. Given that, I’m surprised this code works, and I think we may need a different approach to remain robust in the future.
(In reply to comment #3) > Given that NSString is a class cluster, allocating a string with methods of > NSString can create an object of a class derived from NSString, not NSString > itself. Given that, I’m surprised this code works, and I think we may need a > different approach to remain robust in the future. Note that the objectClass variable in encodeObject() is initialized with [object classForCoder], not [object class]. The NSString implementation of -classForCoder returns NSString, and the concrete subclasses (in Foundation) don’t override it, so they all encode as NSString. Similarly, all (Foundation) concrete subclasses of NSMutableString encode as NSMutableString. The assumption here is that anything that encodes as an NSString or NSMutableString uses the Foundation encoder that has the bug that r184026 was meant to work around, and that any subclass that has a different classForCoder probably uses a different encoder that doesn’t have the bug.
OK, great!