Currently the text editor relies on \n being the only line separator. DOS files have \r\n as line separators, and they should be preserved when the text is retrieved from the text editor (e.g. when saving edited stylesheets).
Created attachment 89560 [details] Patch
Comment on attachment 89560 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=89560&action=review > Source/WebCore/inspector/front-end/SourceFrame.js:40 > + this._textModel.useWindowsLineBreaks = (WebInspector.platform === "windows"); You seem to detect the line break model based on the client OS, while a browser can load pages authored on any OS. You should analyze the input to detect the input document line break model instead.
Created attachment 89573 [details] Patch
Comment on attachment 89573 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=89573&action=review Looks good, with one comment. > Source/WebCore/inspector/front-end/TextEditorModel.js:119 > + var newLines = text.split(/\r?\n/); Why not this._lineBreak ? It would be consistent with the "join" counterpart calls below.
Just to deal with weird cases of mixed line breaks, if any. We never want invisible chars (like \r) to appear in the text editor, because there will be editing artefacts, like deleting zero-width invisible characters...
(In reply to comment #5) > Just to deal with weird cases of mixed line breaks, if any. We never want invisible chars (like \r) to appear in the text editor, because there will be editing artefacts, like deleting zero-width invisible characters... I get it. Fair point. Waiting for someone to r+.
Comment on attachment 89573 [details] Patch Clearing flags on attachment: 89573 Committed r83983: <http://trac.webkit.org/changeset/83983>
All reviewed patches have been landed. Closing bug.