[Webkit-unassigned] [Bug 113240] TextIterator emits LF for a br element inside an empty textarea element
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Mon Mar 25 17:24:47 PDT 2013
https://bugs.webkit.org/show_bug.cgi?id=113240
--- Comment #9 from Aurimas Liutikas <aurimas at chromium.org> 2013-03-25 17:27:14 PST ---
(From update of attachment 194939)
View in context: https://bugs.webkit.org/attachment.cgi?id=194939&action=review
>>>> Source/WebCore/editing/TextIterator.cpp:757
>>>> + return emitsOriginalText || !(node->isInShadowTree() && (node->shadowHost()->toInputElement() || isHTMLTextAreaElement(node->shadowHost())));
>>>
>>> How does this work? This code change will make it so that we never emit new lines for BRs inside textarea.
>>> We need to emit BRs between lines.
>>
>> In Chromium each new line seems to be a new text node. Is that not the case for Safari?
>
> That's not always true even in Chromium. I mean… that's the entire reason we have this bug, right?
Every time I saw a <br> element in Chromium, it did not represent a new line and instead was just a place holder to prevent the <div> in the shadow DOM from collapsing (e.g. when you delete the last character). Do you have specific cases in mind where <br> should become a "\n"?
On the side note, I am really confused why <br> are used in the first place. It does not seem appropriate at all, it would be some much cleaner if we had empty text node inside the <div> in the shadow tree instead of a <br> that should not be emitting.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list