Bug 87330 - Copy / paste inside PRE element re-inserts PRE element
Summary: Copy / paste inside PRE element re-inserts PRE element
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Windows 7
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-23 18:49 PDT by jaroslav.benc
Modified: 2022-05-31 20:24 PDT (History)
7 users (show)

See Also:

Attachments
test case (430 bytes, text/html)
2012-05-23 18:50 PDT, jaroslav.benc 		no flags Details
work in progress (26.11 KB, patch)
2012-07-11 10:20 PDT, Ryosuke Niwa 		no flags Details | Formatted Diff | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description jaroslav.benc 2012-05-23 18:49:48 PDT 
<pre contentEditable="true">copyAndPasteMe</pre> results in: 

<pre style="border:1px solid black">
	<pre style="border: 1px solid black; ">
copyAndPasteMe
	</pre>
</pre>

when copyAndPasteMe is selected/copied/pasted

Visually same result: 
<div style="white-space:pre" contentEditable="true">copyAndPasteMe</div>

so there is no workaround

Note that it works well when pasting as plain text.

Online example: http://coderun.com/ide/ (create a file and copy/paste)

Not sure when this started, tested in Chrome 19+
Comment 1 jaroslav.benc 2012-05-23 18:50:32 PDT 
Created attachment 143701 [details]
test case
Comment 2 Ryosuke Niwa 2012-06-28 12:22:18 PDT 
The problem here is that pre has contenteditable so:

    if ((selectionStartWasStartOfParagraph && selectionEndWasEndOfParagraph && !startIsInsideMailBlockquote) ||
        startBlock == currentRoot || isListItem(startBlock) || selectionIsPlainText)
        m_preventNesting = false;

sets m_preventNesting false because startBlock is currentRoot. We should probably not set m_preventNesting false here in this case, and do this check later when we actually try to prevent nesting.
Comment 3 Ryosuke Niwa 2012-06-28 22:44:41 PDT 
Actually, all we need to do is to fix the FIXME added in:
http://trac.webkit.org/changeset/98899/trunk/Source/WebCore/editing/ReplaceSelectionCommand.cpp
Comment 4 Ryosuke Niwa 2012-07-11 10:20:42 PDT 
Created attachment 151728 [details]
work in progress
Comment 5 Ahmad Saleem 2022-05-31 15:37:35 PDT 
I am not able to reproduce this bug in Safari 15.5 on macOS 12.4. It matches other browsers.

Chrome Canary 104 - no <pre> or extra line added.
Firefox Nightly - no <pre> or extra line added.

It might have been fixed over the course or if I am testing it incorrectly, please retest accordingly. Else it can be marked as "RESOLVED CONFIGURATION CHANGED". Thanks!
Comment 6 Alexey Proskuryakov 2022-05-31 20:24:51 PDT 
I'm still getting the expected behavior from Firefox 101, but not from Safari or Chrome.