Originally reported at http://crbug.com/88736. A fix will come shortly.
Created attachment 100608 [details] Patch
(In reply to comment #1) > Created an attachment (id=100608) [details] > Patch I think your patch will fix the problem. But can we avoid to insert <div> or something into the inner text of <textarea> and <input>?
Comment on attachment 100608 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=100608&action=review > LayoutTests/editing/pasteboard/paste-textarea-wrap.html:36 > +description("This tests if pasted text preserves original line-breaks regardless their destination styles."); Nit: regardless *of* their destination styles.
(In reply to comment #2) > (In reply to comment #1) > > Created an attachment (id=100608) [details] [details] > > Patch > > I think your patch will fix the problem. But can we avoid to insert <div> or something into the inner text of <textarea> and <input>? Yeah, we specifically avoid inserting div into the shadow DOM in various places. We should figure out where this div is coming from and replace them with br's.
> > I think your patch will fix the problem. But can we avoid to insert <div> or something into the inner text of <textarea> and <input>? > > Yeah, we specifically avoid inserting div into the shadow DOM in various places. We should figure out where this div is coming from and replace them with br's. Kent-san, Ryosuke, thanks for taking a look! I'm not sure what should happen there. So I'll investigate how text insertion works at first.
Created attachment 102122 [details] Patch
> > I think your patch will fix the problem. But can we avoid to insert <div> or something into the inner text of <textarea> and <input>? > > Yeah, we specifically avoid inserting div into the shadow DOM in various places. We should figure out where this div is coming from and replace them with br's. I updated the patch to use <br>. Niwa-san, could you take a look?
Comment on attachment 102122 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=102122&action=review > Source/WebCore/editing/markup.cpp:772 > + element = createHTMLElement(document, spanTag); > + fillContainerFromString(element.get(), s); > + fragment->appendChild(element.release(), ASSERT_NO_EXCEPTION); > + element = createBreakElement(document); > + fragment->appendChild(element.release(), ASSERT_NO_EXCEPTION); This seems like a wrong layer to fix this. I'd suspect where we need to fix is ReplaceSelectionCommand.
Comment on attachment 102122 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=102122&action=review >> Source/WebCore/editing/markup.cpp:772 >> + fragment->appendChild(element.release(), ASSERT_NO_EXCEPTION); > > This seems like a wrong layer to fix this. I'd suspect where we need to fix is ReplaceSelectionCommand. I don't think so. ReplaceSelectionCommand just emits a textInput event, And Editor handles it, then calls this method. Actually this createFragmentFromText() has similar trick at the beginning of the function for preserveNewLine(). Hopefully we have FragmentBuilder to make these code more organized, like MarkupAccumulator does. But that's another story.
Comment on attachment 102122 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=102122&action=review >>> Source/WebCore/editing/markup.cpp:772 >>> + fragment->appendChild(element.release(), ASSERT_NO_EXCEPTION); >> >> This seems like a wrong layer to fix this. I'd suspect where we need to fix is ReplaceSelectionCommand. > > I don't think so. > ReplaceSelectionCommand just emits a textInput event, > And Editor handles it, then calls this method. > Actually this createFragmentFromText() has similar trick at the beginning of the function for preserveNewLine(). > > Hopefully we have FragmentBuilder to make these code more organized, like MarkupAccumulator does. > But that's another story. Actually, the fragment is build _before_ ReplaceSelectionCommand_ is instantiated, The created fragment is passed to ReplaceSelectionCommand constructor instead. So there is nothing to do for ReplaceSelectionCommand.
Comment on attachment 102122 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=102122&action=review >>>> Source/WebCore/editing/markup.cpp:772 >>>> + fragment->appendChild(element.release(), ASSERT_NO_EXCEPTION); >>> >>> This seems like a wrong layer to fix this. I'd suspect where we need to fix is ReplaceSelectionCommand. >> >> I don't think so. >> ReplaceSelectionCommand just emits a textInput event, >> And Editor handles it, then calls this method. >> Actually this createFragmentFromText() has similar trick at the beginning of the function for preserveNewLine(). >> >> Hopefully we have FragmentBuilder to make these code more organized, like MarkupAccumulator does. >> But that's another story. > > Actually, the fragment is build _before_ ReplaceSelectionCommand_ is instantiated, > The created fragment is passed to ReplaceSelectionCommand constructor instead. > So there is nothing to do for ReplaceSelectionCommand. What I'm saying that createFragment changing behavior depending on whether we're inside a shadow DOM or not seems wrong.
For example, are you sure that this bug doesn't reproduce in a contenteditable area that has the exactly same CSS style as the one in the shadow DOM of textarea?
Comment on attachment 102122 [details] Patch Clearing r? for now.
Oops, I had totally forgot about this bug and made a very similar change in http://trac.webkit.org/changeset/102392. Sorry about that :(