Closed Bug 1117007 Opened 10 years ago Closed 10 years ago

Copying from content-editable and then pasting that into content editable destroys line breaks

Categories

(Core :: DOM: Editor, defect)

Product:
Core
Component:
DOM: Editor
Version:
37 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1119503

People

(Reporter: john, Unassigned)

References

Details

(Keywords: regression, reproducible, testcase)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:34.0) Gecko/20100101 Firefox/34.0 Build ID: 20141127111021 Steps to reproduce: Copy / Paste any content with line breaks. Track here: https://github.com/ether/etherpad-lite/issues/2407 Steps to replicate: 1. Copy Paste the entire contents of this bug report. 2. Paste it into a contentEditable element IE a pad on http://beta.etherpad.org Actual results: Line Breaks are destroyed Expected results: Line Breaks are maintained
http://beta.etherpad.org/ doesn't work... Is there another way to test this bug?
Component: Untriaged → Editor
Flags: needinfo?(john)
Product: Firefox → Core
Sorry, we were doing some maintenance. It's available now.
Flags: needinfo?(john)
The page still doesn't work
Flags: needinfo?(john)
Again you caught it when we were doing maintenance.. It's available now.. You can also test this locally by downloading Etherpad from http://etherpad.org should you wish.
Flags: needinfo?(john)
WFM in Firefox 35 (https://beta.mozilla.org, to be released this week) on OS X: http://beta.etherpad.org/p/bug1117007-test Can you still reproduce on 34? Have you tried in safe mode? ( help > restart with add-ons disabled )
Flags: needinfo?(john)
Firefox 38 Nightly has this issue. Can reproduce in safe mode.
Flags: needinfo?(john)
(In reply to John McLear from comment #6) > Firefox 38 Nightly has this issue. > > Can reproduce in safe mode. Oh! Your initial report listed a UA of 34. Sorry. Oddly, I also can't reproduce in Nightly from the 11th... do you have e10s turned on? Either way, safe mode would turn that off. That's very odd. Have you tried a clean profile yet, and if not, could you, please? And/or am I just copying the wrong bit of text (I'm just copying the text from your initial comment #0) Hmm, or maybe it's Linux only - I'm testing on OS X. Will check in a second.
Nope, not seeing this on Linux either. :-\
Copy / Paste the content from inside the pad.
(In reply to John McLear from comment #9) > Copy / Paste the content from inside the pad. Ah, there we go! Ehsan, thoughts on this? This works on 35 and is broken on 37/38, so looks like a regression...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(ehsan)
Keywords: regression, regressionwindow-wanted, reproducible, testcase
OS: Linux → All
Hardware: x86_64 → All
Summary: Pasting into content editable destroys line breaks → Copying from content-editable and then pasting that into content editable destroys line breaks
Can you guys please assist with bisecting this to the commit that broke things? Thanks!
Flags: needinfo?(twalker)
Flags: needinfo?(anthony.s.hughes)
I can reproduce on Mac, so I'll find the regression window. STR's: 1. Copy the entire contents of this bug report. 2. Paste it into a contentEditable element. ie. a pad on http://beta.etherpad.org/p/test_1117007 3. Copy the entire pad contents 4. Select All in the pad and delete the contents 5. Paste clipboard back into the pad As reported, line breaks are lost.
Flags: needinfo?(anthony.s.hughes)
I am not sure how to explain this, but here goes. It looks like this broke in two phases: First, between nightly builds of 20141130 and 20141201 (http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=df3fc7cb7e80&tochange=af5fc587f98b). Where in the latter, line returns are maintained but all other white space is lost. For the next nightly build of 20141202 (http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=af5fc587f98b&tochange=22ad8a162cf3), line returns are lost. seems likely blame is: http://hg.mozilla.org/mozilla-central/rev/d5ef728a519d Ehsan Akhgari — Bug 116083 - Correctly handle the whitespace in all preformatted elements; r=roc "Previously this code only handled the special case of a <body> element that had an explicit style attribute, which doesn't really make sense. Now we do the right thing based on the computed white-space style."
Flags: needinfo?(twalker)
Hmm, this could be another manifestation of bug 1119503.
See Also: → https://bugzilla.mozilla.org/show_bug.cgi?id=1119503
[Tracking Requested - why for this release]:
status-firefox37: --- → affected
tracking-firefox37: --- → ?
Flags: needinfo?(ehsan)
[Tracking Requested - why for this release]:
status-firefox38: --- → affected
tracking-firefox38: --- → ?
Flags: needinfo?(ehsan)
I can reproduce the problem on the etherpad ONLY. I CANNOT reproduce on TinyMCE, CKEditor and www-archive.mozilla.org/editor/midasdemo/ . Regression pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e12130225335&tochange=d5ef728a519d
Blocks: 116083
Keywords: regressionwindow-wanted
This will be fixed by my patch in bug 1119503.
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(ehsan)
Resolution: --- → DUPLICATE
Clearing tracking and status flags. Dup already has tracking noms.
status-firefox37: affected → ---
status-firefox38: affected → ---
tracking-firefox37: ? → ---
tracking-firefox38: ? → ---
You need to log in before you can comment on or make changes to this bug.