<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugs.webkit.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.4.1"
          urlbase="https://bugs.webkit.org/"
          
          maintainer="admin@webkit.org"
>

    <bug>
          <bug_id>147249</bug_id>
          
          <creation_ts>2015-07-23 19:24:21 -0700</creation_ts>
          <short_desc>REGRESSION (r184026): Safari AutoFill with Contact info for phone number is broken</short_desc>
          <delta_ts>2015-07-26 20:31:00 -0700</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>WebKit</product>
          <component>WebKit2</component>
          <version>528+ (Nightly build)</version>
          <rep_platform>Unspecified</rep_platform>
          <op_sys>Unspecified</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords>InRadar, Regression</keywords>
          <priority>P1</priority>
          <bug_severity>Normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter>mitz</reporter>
          <assigned_to>mitz</assigned_to>
          <cc>andersca</cc>
    
    <cc>darin</cc>
    
    <cc>mitz</cc>
    
    <cc>sam</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>1111881</commentid>
    <comment_count>0</comment_count>
    <who name="">mitz</who>
    <bug_when>2015-07-23 19:24:21 -0700</bug_when>
    <thetext>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 &lt;http://trac.webkit.org/changeset/184026&gt; 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.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1111920</commentid>
    <comment_count>1</comment_count>
      <attachid>257435</attachid>
    <who name="">mitz</who>
    <bug_when>2015-07-23 21:45:05 -0700</bug_when>
    <thetext>Created attachment 257435
Use custom string coding for NSString and NSMutableString only</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1111921</commentid>
    <comment_count>2</comment_count>
    <who name="">mitz</who>
    <bug_when>2015-07-23 21:55:10 -0700</bug_when>
    <thetext>Fixed in &lt;http://trac.webkit.org/r187288&gt;.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1112335</commentid>
    <comment_count>3</comment_count>
    <who name="Darin Adler">darin</who>
    <bug_when>2015-07-26 20:16:36 -0700</bug_when>
    <thetext>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.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1112339</commentid>
    <comment_count>4</comment_count>
    <who name="">mitz</who>
    <bug_when>2015-07-26 20:27:45 -0700</bug_when>
    <thetext>(In reply to comment #3)
&gt; Given that NSString is a class cluster, allocating a string with methods of
&gt; NSString can create an object of a class derived from NSString, not NSString
&gt; itself. Given that, I’m surprised this code works, and I think we may need a
&gt; 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.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1112341</commentid>
    <comment_count>5</comment_count>
    <who name="Darin Adler">darin</who>
    <bug_when>2015-07-26 20:31:00 -0700</bug_when>
    <thetext>OK, great!</thetext>
  </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>257435</attachid>
            <date>2015-07-23 21:45:05 -0700</date>
            <delta_ts>2015-07-23 21:52:31 -0700</delta_ts>
            <desc>Use custom string coding for NSString and NSMutableString only</desc>
            <filename>bug-147249-20150723214349.patch</filename>
            <type>text/plain</type>
            <size>1945</size>
            <attacher>mitz</attacher>
            
              <data encoding="base64">SW5kZXg6IFNvdXJjZS9XZWJLaXQyL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi
S2l0Mi9DaGFuZ2VMb2cJKHJldmlzaW9uIDE4NzI4MikKKysrIFNvdXJjZS9XZWJLaXQyL0NoYW5n
ZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDE1IEBACisyMDE1LTA3LTIzICBEYW4gQmVy
bnN0ZWluICA8bWl0ekBhcHBsZS5jb20+CisKKyAgICAgICAgPHJkYXI6Ly9wcm9ibGVtLzIxOTI5
NTMyPiBSRUdSRVNTSU9OIChyMTg0MDI2KTogU2FmYXJpIEF1dG9GaWxsIHdpdGggQ29udGFjdCBp
bmZvIGZvciBwaG9uZSBudW1iZXIgaXMgYnJva2VuCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJr
aXQub3JnL3Nob3dfYnVnLmNnaT9pZD0xNDcyNDkKKworICAgICAgICBSZXZpZXdlZCBieSBOT0JP
RFkgKE9PUFMhKS4KKworICAgICAgICAqIFNoYXJlZC9BUEkvQ29jb2EvV0tSZW1vdGVPYmplY3RD
b2Rlci5tbToKKyAgICAgICAgKGVuY29kZU9iamVjdCk6IFVzZSBlbmNvZGVTdHJpbmcgb25seSBm
b3Igc3RyaW5ncyB0aGF0IGVuY29kZSBhcyBOU1N0cmluZyBvcgorICAgICAgICBOU011dGFibGVT
dHJpbmcuIEl0IGNhbuKAmXQgZW5jb2RlIGFyYml0cmFyeSBOU1N0cmluZyBzdWJjbGFzc2VzLgor
ICAgICAgICAoZGVjb2RlT2JqZWN0KTogVXNlIGRlY29kZVN0cmluZyBmb3IgTlNNdXRhYmxlU3Ry
aW5nIGFzIHdlbGwuCisKIDIwMTUtMDctMjMgIE1hdHRoZXcgRGFpdGVyICA8bWRhaXRlckBhcHBs
ZS5jb20+CiAKICAgICAgICAgTGlua2luZyBXZWJLaXQyIHRvIGJlIGFibGUgdG8gZ3JhYiBtZWRp
YSBzb3VyY2VzIGZyb20gYSBVSUQKSW5kZXg6IFNvdXJjZS9XZWJLaXQyL1NoYXJlZC9BUEkvQ29j
b2EvV0tSZW1vdGVPYmplY3RDb2Rlci5tbQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2ViS2l0Mi9T
aGFyZWQvQVBJL0NvY29hL1dLUmVtb3RlT2JqZWN0Q29kZXIubW0JKHJldmlzaW9uIDE4NzI2NSkK
KysrIFNvdXJjZS9XZWJLaXQyL1NoYXJlZC9BUEkvQ29jb2EvV0tSZW1vdGVPYmplY3RDb2Rlci5t
bQkod29ya2luZyBjb3B5KQpAQCAtMjQxLDcgKzI0MSw3IEBAIHN0YXRpYyB2b2lkIGVuY29kZU9i
amVjdChXS1JlbW90ZU9iamVjdEUKICAgICAgICAgcmV0dXJuOwogICAgIH0KIAotICAgIGlmIChb
b2JqZWN0IGlzS2luZE9mQ2xhc3M6W05TU3RyaW5nIGNsYXNzXV0pIHsKKyAgICBpZiAob2JqZWN0
Q2xhc3MgPT0gW05TU3RyaW5nIGNsYXNzXSB8fCBvYmplY3RDbGFzcyA9PSBbTlNNdXRhYmxlU3Ry
aW5nIGNsYXNzXSkgewogICAgICAgICBlbmNvZGVTdHJpbmcoZW5jb2Rlciwgb2JqZWN0KTsKICAg
ICAgICAgcmV0dXJuOwogICAgIH0KQEAgLTU4Niw2ICs1ODYsOSBAQCBzdGF0aWMgaWQgZGVjb2Rl
T2JqZWN0KFdLUmVtb3RlT2JqZWN0RGVjCiAgICAgaWYgKG9iamVjdENsYXNzID09IFtOU1N0cmlu
ZyBjbGFzc10pCiAgICAgICAgIHJldHVybiBkZWNvZGVTdHJpbmcoZGVjb2Rlcik7CiAKKyAgICBp
ZiAob2JqZWN0Q2xhc3MgPT0gW05TTXV0YWJsZVN0cmluZyBjbGFzc10pCisgICAgICAgIHJldHVy
biBbTlNNdXRhYmxlU3RyaW5nIHN0cmluZ1dpdGhTdHJpbmc6ZGVjb2RlU3RyaW5nKGRlY29kZXIp
XTsKKwogICAgIGlkIHJlc3VsdCA9IFtvYmplY3RDbGFzcyBhbGxvY1dpdGhab25lOmRlY29kZXIu
em9uZV07CiAgICAgaWYgKCFyZXN1bHQpCiAgICAgICAgIFtOU0V4Y2VwdGlvbiByYWlzZTpOU0lu
dmFsaWRVbmFyY2hpdmVPcGVyYXRpb25FeGNlcHRpb24gZm9ybWF0OkAiQ2xhc3MgXCIlc1wiIHJl
dHVybmVkIG5pbCBmcm9tICthbGxvYyB3aGlsZSBiZWluZyBkZWNvZGVkIiwgY2xhc3NOYW1lLmRh
dGEoKV07Cg==
</data>
<flag name="review"
          id="282595"
          type_id="1"
          status="+"
          setter="sam"
    />
          </attachment>
      

    </bug>

</bugzilla>