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