On Jun 20, 2005, at 3:03 PM, Darin Adler wrote:
I think that ideally this translation should occur when text gets into a text area; then we would have no need to handle these odd cases later. This would be a bit challenging because NSTextView has various code paths for inserting text, and we'd have to cover all of those.
I agree, that would be best, but as you said, there's multiple code paths for inserting text.
Another issue related to this is KWQTextArea has accessors for the cursor position (but not the selection - odd), which do not take into account the translation. I'm not entirely sure how to test this, since they're only used when updating the widget, and I haven't looked at this enough to figure out how to actually trigger that, but I imagine it could cause the cursor position to change based on the \r\n translation. But this is actually fixable once the above issue is dealt with.
Good point. You should keep at it and come up with the test case that shows this is broken.
It's not broken if we translate the text on insertion, only in the current situation where we translate on retrieval. But I will try to figure out how this is being used and how to reproduce the issue.
Should we translate the text when setting it from Javascript? But that makes HTMLTextAreaElementImpl acquire behaviour that was hidden down in KWQTextArea, behaviour that I don't if it should belong in HTMLTextAreaElementImpl.
I think that would be an acceptable solution, and probably the easiest thing to get right.
The heart of the matter here is that NSTextView can handle all three types of line endings, and makes no attempt to unify them as text is inserted. Yet we want to have the line ending always be a single standard one.
This would probably be the easiest thing to get right, but then we'd have to think about the other ways of setting text, such as pasting text in with multiple line endings. Sure, we'd still return the "correct" value when accessed, but the internal storage would still contain \r\n sequences and the accessors for the cursor position and selected text would have to be aware of that. It's just something to think about.
I think one of the reasons it's cached might be that the value needs to survive the process of destroying and re-creating the renderer.
Ah, makes sense
RenderTextArea::updateFromElement pushes the value from the DOM into the QTextEdit (which in turn uses KWQTextArea). In the case of a setValue call, HTMLTextAreaElementImpl::setValue calls setChanged (true), which results in an updateFromElement call later.
It's the "results in an updateFromElement call later" that's the problem. If we're not pushing it down to the QTextEdit at the time it's set, we can't invalidate the cached value there, and invalidating it in updateFromElement doesn't make sense, plus it would leave open a window in which the "incorrect" value (i.e. with \r \n sequences) could still be retrieved. I guess it comes down to the following options: 1) We translate the text whenever it gets set from anywhere so that all line endings are \n. This has the benefit of making the cursor position and selection accessors much easier to write, since the internal text storage is the same as what's exposed to the outside. However, this has the problem of requiring translation on all the different ways text can get into the NSTextView 2) We translate text set up in HTMLTextAreaElementImpl whenever it's set from there (or we force a updateFromElement and then invalidate the cache so that the next access will get it from KWQTextArea). This has the benefit of being pretty easy to do, with the negative of requiring the cursor position and selection accessors to be aware of \r\n sequences and treat them as a single char 3) We stop translating the text. This is probably not desired, because at least Firefox always translates \r\n sequences to \n (I don't have any way to test WinIE) and compatibility with other browsers is a good thing. Given that, I'm not actually aware of any spec that says line endings should be coerced to \n. I personally vote for option #2. -- Kevin Ballard kevin@sb.org http://www.tildesoft.com http://kevin.sb.org