[webkit-dev] Newline translation issue with textareas

[Darin Adler]

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