On Jun 19, 2005, at 12:17 PM, Kevin Ballard wrote:
I discovered that KWQTextArea translates \r\n sequences (and just plain \r sequences) to \n when returning its text value.
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.
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.
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.
Should we stop caching the text value in HTMLTextAreaElementImpl? I'm not sure why it is cached, AFAIK it's not something that's being accessed over and over, the only real benefit to caching is to avoid translating the NSString to a QString each time it's accessed.
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.
Should we invalidate the cached value when setting a new value in code? I'm not sure how to do that, because I'm not sure where the set value is pushed down to the KWQTextArea.
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. -- Darin