[webkit-dev] Newline translation issue with textareas
kevin at sb.org
Mon Jun 20 13:00:24 PDT 2005
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.
>> 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
> 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
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 at sb.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2378 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/webkit-dev/attachments/20050620/0071bea1/smime.bin
More information about the webkit-dev