Did we hardcode this wrong?

The following test code produces U+A (Line Feed) for me on Linux with Flash:

package {
    import flash.display.Sprite;
    import flash.events.TextEvent;
    import flash.text.TextField;
    import flash.text.TextFieldType;

    public class Test extends Sprite {
        public function Test() {
            var textField = new TextField();
            textField.type = TextFieldType.INPUT;
            textField.border = true;
            textField.multiline = true;
            textField.height = 200;
            textField.addEventListener(TextEvent.TEXT_INPUT, onInput);
            addChild(textField);
        }

        public function onInput(evt: TextEvent) {
            trace("onInput: U+" + evt.text.charCodeAt(0).toString(16).toUpperCase() + " " + evt.text.length);
        }
    }
}

I believe Flash is just weird with newlines. We should write some tests related to newlines in every possible place that a newline might allear. I believe Flash uses internally CR for newlines, but sometimes surfaces it as LF to the user.

Ah, I think I know what you mean. Entering [A] [Enter] [B] produces the "textInput" events A, Line Feed (U+A) and B. But the text property of the TextField contains Carriage Return (U+D).

I think we should also replace LF with CR when setting the text (e.g. field.text = 'a\nb'). Which would mean Flash is likely to use LF on the user level and CR on the text field level, so pressing enter would generate a LF, but it would be latter replaced with a CR.

At least for the KEY_DOWN event Flash also uses a CR. (#19518)

I remember that years ago I had read somewhere that Flash expect the newline that user input is \n (LF) and what Flash output when you get the .text property is \r (CR).

So in this case the event.text is what user input so it should be \n.

There's no problem if user input \r I think, Flash still will show a new line, but it can break existing apps if a developer do a check if (event.text == "\n")