[webkit-dev] Newline translation issue with textareas

[Kevin Ballard]

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 at sb.org
http://www.tildesoft.com
http://kevin.sb.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2378 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/webkit-dev/attachments/20050620/0071bea1/smime.bin