Bug 187571

Summary: UTF-16 XHTML files need svn:mime-type to be handled correctly by Windows SVN
Product: WebKit Reporter: Ross Kirsling <ross.kirsling>
Component: Tools / TestsAssignee: Ross Kirsling <ross.kirsling>
Status: RESOLVED FIXED    
Severity: Normal CC: achristensen, bfulgham, commit-queue, don.olmstead, Hironori.Fujii, lforschler, pvollan, stephan.szabo, webkit-bug-importer, ysuzuki
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 187614    
Bug Blocks:    
Attachments:
Description Flags
Patch
none
Patch (manual)
none
Patch (manual)
none
Patch (manual) achristensen: review+

Description Ross Kirsling 2018-07-11 17:24:35 PDT
UTF-16 XHTML files need svn:mime-type to be handled correctly by Windows SVN
Comment 1 Ross Kirsling 2018-07-11 17:33:17 PDT
Created attachment 344794 [details]
Patch
Comment 2 Ross Kirsling 2018-07-11 17:37:26 PDT
Created attachment 344797 [details]
Patch (manual)
Comment 3 Ross Kirsling 2018-07-11 17:44:35 PDT
What's currently happening is that when Windows SVN turns upstream LFs into local CRLFs, it's not realizing that the files are UTF-16 and so it turns 00 0A into the invalid sequence 00 0D 0A instead of the correct 00 0D 00 0A.

This does not occur for dom/xhtml/level3/core/documentgetxmlencoding03.xhtml, which already has svn:mime-type set to text/xml, therefore adding this property to the other three files should rectify the issue.
Comment 4 Ross Kirsling 2018-07-11 17:52:05 PDT
Created attachment 344799 [details]
Patch (manual)
Comment 5 Ross Kirsling 2018-07-11 18:27:19 PDT
Wow. This isn't submittable via webkit-patch so I'm having to manually upload an `svn diff`, but it seems the patch won't apply purely because the revision number keeps changing upstream?

It may be necessary to land this manually.
Comment 7 Ross Kirsling 2018-07-11 19:26:54 PDT
(In reply to Fujii Hironori from comment #6)
> I think you shold remove 'svn:eol-style' property.
> http://svnbook.red-bean.com/en/1.7/svn.advanced.props.file-portability.
> html#svn.advanced.props.special.eol-style

I believe this shouldn't matter, as it seems that 00 0D will be inserted on Windows either way, but I can do so for consistency.

> There is one more UTF-16 file, external_foo.ent. Do you need to change this,
> too?

Interesting! Looks like that one's not having problems because it doesn't contain a newline, but it too could be updated for consistency.
Comment 8 Ross Kirsling 2018-07-11 20:16:40 PDT
Created attachment 344815 [details]
Patch (manual)
Comment 9 Ross Kirsling 2018-07-11 20:26:05 PDT
At any rate, the attached file can be `svn patch`ed locally without issue.
Comment 10 Fujii Hironori 2018-07-12 02:50:13 PDT
(In reply to Ross Kirsling from comment #7)
> (In reply to Fujii Hironori from comment #6)
> > I think you shold remove 'svn:eol-style' property.
> > http://svnbook.red-bean.com/en/1.7/svn.advanced.props.file-portability.
> > html#svn.advanced.props.special.eol-style
> 
> I believe this shouldn't matter, as it seems that 00 0D will be inserted on
> Windows either way, but I can do so for consistency.

For example,
http://svn.webkit.org/repository/webkit/trunk/LayoutTests/fast/css/visited-link-hang-expected.txt
has only svn:eol-style:native, but no svn:mime-type.
If this file is checked out by using Windows SVN, it will be converted to CR-LF style.
Comment 11 Alex Christensen 2018-07-12 10:50:26 PDT
Comment on attachment 344815 [details]
Patch (manual)

r=me
You'll probably need to manually commit this with svn commit.
Comment 12 Ross Kirsling 2018-07-12 12:07:59 PDT
Committed r233776: <https://trac.webkit.org/changeset/233776>
Comment 13 Radar WebKit Bug Importer 2018-07-12 12:08:19 PDT
<rdar://problem/42131850>
Comment 14 WebKit Commit Bot 2018-07-12 12:11:05 PDT
Re-opened since this is blocked by bug 187614
Comment 15 Ross Kirsling 2018-07-12 12:53:50 PDT
ChangeLog ended up in r233776, propsets in r233779:
https://trac.webkit.org/changeset/233779/webkit

Sorry for the ruckus.