[webkit-dev] Newline translation issue with textareas

[Kevin Ballard]

I'm trying to solve <http://bugzilla.opendarwin.org/show_bug.cgi? 
id=3401>, which involves writing accessors for the selection on  
QTextEdit and KWQTextArea. After poking around, I discovered that  
KWQTextArea translates \r\n sequences (and just plain \r sequences)  
to \n when returning its text value. This makes a certain amount of  
sense, because standardizing newlines can be helpful at times, and  
Firefox also exhibits this behaviour when tested. However, WebKit has  
a problem with this. If I set the value of a textarea in ecmascript  
to "A\r\ntext\r\nfield" and fetch the value back out, the \r\n  
sequences are still there. Only if I change the value of the textarea  
by hand do the sequences get translated. After examining the code,  
I'm guessing this is because HTMLTextAreaElementImpl caches the value  
of the textarea and simply returns that cached value if the  
NSTextView widget hasn't been touched. And since the translation  
happens down in KWQTextArea, the returned value still contains the \r\n.

As you can imagine, this causes quite a few problems when trying to  
handle the selection, since the selection can stay the same and the  
text change underneath it, since the selection isn't cached in  
HTMLTextAreaElementImpl and will always be fetched from the  
KWQTextArea (at least, as of this writing - I see no reason to try to  
cache it), so the selection will always be given assuming the  
translation is in place (which is another issue - I have to modify  
the real selection to return the perceived selection, since the  
NSTextView's text still contains the \r\n sequences, KWQTextArea  
simply translates when returning the text value)

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.

Anyway, I'm looking for a solution to the problem outlined above.  
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. 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. 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.

Does anybody who has more experience with this code than a single day  
have any comments or suggestions for this problem?

-- 
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/20050619/139e695c/smime.bin