[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