189250 - Composer edited files are diff-unfriendly

Status: RESOLVED WONTFIX

(Core :: DOM: Serializers, defect, P5)

Description

[benc]

I believe Myk initially mentioned to me that there were problems with some of
the files I had editied on Mozilla.org, and we suspected that Composer was doing
some kind of dynamic reflow of whitespace in the HTML when you hit save, which
made the files incredibly diff unfriendly (the whole document would diff in one
line).

I mentioned this to syd, who said that "if composer does that, it cannot be
fixed, because there are a lot of things that happen as you click around in
composer."

Recently, cls noticed that this might be a Mac-only composer problem, where the
end of line is handled differently.

I'm not that familiar with how this works, but I think it is time to file a bug
and figure out what is going on. 

I'll try to find an example of this in bonzai and put it into the URL field.

Comment 1

[Dave Miller [:justdave]]

If the whole document is diffing in one line, it sounds like it's using Mac line
endings.  It won't help for Mac OS 9 builds, but there's no reason the OS X
version can't use Unix line endings.  All of the OS X native apps that use the
OS-provided mechanisms for dealing with text can handle either format, and most
command-line stuff on OS X still only uses Unix endings.  My wife and I did a
web page in Composer a few days ago, then I opened it from the command line in
vim to fix up some of the formatting before uploading it, and had to run cr2lf
on it first before I could edit it in vim :-)

Although if the line endings are really what the problem is, I'd say that's a
misconfigured cvs client on the part of whoever's trying to check it in, because
the cvs client should be converting the line endings as it checks in.  Unless of
course you're using the command-line cvs client in OS X, which doesn't do that
because it assumes OS X uses unix line endings...   :-)

Comment 2

[benc]

That person w/ the bad cvs client would be me :(

Okay, I'll look at Mach-O composer, and also see if I can locate and fix the
files I munged w/ the utility you suggested.

Comment 3

[Dave Miller [:justdave]]

actually, that "utility" is a shell script in my ~/bin directory. :)

tcsh> cat ~/bin/cr2lf
#!/bin/sh
cp -p $1 temp.$$  # hack to maintain file permissions
cat $1 | tr '\r' '\n' > temp.$$
mv temp.$$ $1

Comment 4

[hacker formerly known as [e-mail]]

I just verified that the mach-o version of composer does save the file using
unix line-endings.  However, the diff unfriendliness is still there.  I removed
one line of whitespace from the document and it was completely reformatted.

Comment 5

[Kathleen :Brade]

-->Dom to Text Conversion

even though this is filed as a Mac bug, it sounds like it is cross-platform;
could someone verify?

Comment 6

[benc]

It seems like there are two problems, the cfm composer <CR> problem and possibly
a larger cross-platform diff-nasty problem.

Being the primary source of the bad files in the mozilla.org tree (was I the
only person using Composer on Mac OS X?!), I've made some progress understanding
this problem.

identifying cfm created files:

all the files on my local cvs pull seem to have a wc -l of zero (surprisingly,
not even 1). This is probably due to a complete lack of a LF.

fixing cfm created files:

I have found that opening the files in Mach-O and making a single change will
save the files w/ LF. I have tested several files, so this looks good.

As for the larger problems, I did notice that when I diff'd before checkin,
there were some extraneous lines changed around my edits, but nothing as bad as
the whole file. 

I've learned to always diff before commit, so I'll update this bug if I see
other problems.

Comment 7

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority and severity.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I don't think we can solve this issue within the serializer because the serializer does not know how a Text node created from plaintext in the original source code. HTMLEditor normalizes surrounding collapsible white-spaces around edit points. Then, all linefeeds will be converted to an ASCII space or an NBSP. So, this is lossy conversion, but it's required for making the white-spaces visible and simplify the further processing in the editor module.

I think authors should use prettier or something which formats HTML mechanically and do diff.