I have a web application (not AIR/desktop) using the following RichEditableText control in an MXML file:
As implied above, data.htmlTitle is HTML-encoded text having clickable links (then main reason for using RichEditableText).
The text renders as expected and the clickable links work, but the textFlow does not wrap, per the following observations:
1. The first time the textFlow is rendered, the line is simply truncated to the current width alloted to the renderer. Only the first line is rendered (though sometimes a single, apparently random, character appears on the second line).
2. If the browser width is narrowed, the single rendered line is simply truncated more. (The fact that the container width becomes more narrow does not appear to cause the textFlow layout logic to re-render, only to truncate it further).
3. If the browser width is widened, more of the single rendered line is shown, but the entire textFlow is not re-rendered.
4. If the browser width is widened until the entire textFlow fits on a single line, then narrowed, word wrap is engaged and works as expected.
I attempted to set the textFlow programmatically, as follows:
1. I added a data setter override (with direct property setting as below, and also via binding to the tfTitle class member):
tfTitle = TextConverter.importToFlow(FeedItem(data).htmlTitle, TextConverter.TEXT_FIELD_HTML_FORMAT);
tfTitle.breakOpportunity = BreakOpportunity.ANY; // also tried .AUTO
tfTitle.lineBreak = LineBreak.TO_FIT;
contents.textFlow = tfTitle;
2. I tried the same logic in a commitProperties override.
Neither of these attempts worked. However, I observed that if either the data setter override was active, or the commitProperties was active, work wrap did not work at all. That is, only a single line of the textFlow would be rendered, regardless of the container width. Once the data setter and commitProperties were commented out, word wrap would function again (per note 4 above).
Assuming that the issue was with the HTML encoding, I then changed TEXT_FIELD_HTML_FORMAT to PLAIN_TEXT_FORMAT in the call to importToFlow. This had no effect whatever; the same tests performed above were repeatable.