Closed Bug 1426782 Opened 7 years ago Closed 5 years ago

Pasting into an empty paragraph results in an empty paragraph both before and after pasted text

Categories

(developer.mozilla.org Graveyard :: Editing, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: sheppy, Assigned: espressive)

References

Details

(Keywords: in-triage)

First, I'm aware that this is not a useful report yet. I am filing it now because there's definitely a problem, and I want a place where I can track what is and is not causing it so we can get to the bottom of things until I can provide STR. Something that happens while doing a series of edits is resulting in additional empty paragraphs being inserted into articles. I *think* they are always just before a heading, but am not at the moment 100% sure. This is one of the data points I am tracking. I have in the past thought it might have something to do with going in and out of source mode, but now I don't think that's the case. I am nearly certain this is related in some way to actions taken while adding and editing samples; I don't think it matters if they're live ones or not. This may be happening when: * Toggling <pre> on or off * Setting the highlighting brush for a <pre> block (but I don't think so) * Copying and/or pasting <pre> blocks (this one is a good candidate) There may be other possibilities but these are the ones I'm thinking about the most right now. I will keep this up to date as I work on sorting through what's going on.
It appears that the empty paragraphs are happening when switching into source mode, because I can start with an article without them and immediately after switching into source mode I see the "<p>&nbsp;</p>" lines (usually two in a row) added to the article immediately before <h2> blocks.
Keywords: in-triage
Priority: -- → P2
Assignee: nobody → schalk.neethling.bugs
See Also: → 946677
So, further analysis suggests this is happening when pasting in content copied from another page. Although after initially pasting the content everything looks fine, after saving, you wind up with an empty paragraph ("<p>&nbsp;</p>") inserted immediately before and after the content you pasted in.
Further experimenting shows that these "<p>&nbsp;</p>" blocks are being inserted when pasting content that I copied from another MDN editor window. The empty paragraph does not render in the WYSIWYG editor at the time I paste, however, but *is* present in the source editor. Switching to the source editor lets me see the empty paragraphs that got inserted, and switching back to WYSIWYG then shows the empty paragraphs rendered, causing unwanted vertical whitespace.
The latest: If I copy one or more paragraphs or groups of paragraph and/or heading elements from one page, then paste it onto another page, the result is 100% repeatable: I will wind up with empty paragraphs before and after the pasted text. It is not visible immediately after pasting, however. It looks correct on screen. But if I switch to the source mode, the empty paragraphs are visible in source mode, and upon returning to WYWIWYG mode, the empty paragraphs are there. It doesn't happen when copying just a few words from page to page within a paragraph.
Summary: Sometimes editing adds empty paragraphs to articles [analysis ongoing] → Sometimes editing adds empty paragraphs to articles
Oh! One final detail: This only happens if you paste on a new line. If you put the cursor at the beginning of an existing paragraph or heading and then paste, you do not wind up with the empty paragraphs.
Strike all of that (man, I wish I could delete or strike out previous bug comments). *Any* text pasted into a new paragraph will cause this to happen. Doesn't matter if it's a single word or a whole series of paragraphs and headings. Paste anything onto a new line and you get this. This is why it happens so much while editing -- you're working, you go to copy content from page to page, and you hit return then paste because that's how you typically go when inserting paragraphs or other content you already have on the clipboard.
Summary: Sometimes editing adds empty paragraphs to articles → Pasting
Summary: Pasting → Pasting into an empty paragraph results in an empty paragraph both before and after pasted text
Just realized that I was not mentioning: when copying, you need to be in the editor as well. You always need to copy from the editor if you plan to paste back into the editor, because otherwise you can wind up with style problems.
I tried copying text from one visual CKEditor window to another visual CKEditor window, and the empty paragraphs were not added. We may need to do a screen sharing session to determine how to reproduce. Or, it could be something else. Can you try in a different browser, or with extensions disabled?
Strange. So, I see similar but not identical behavior in Safari. Safari is winding up with an empty paragraph before and after, but the after one goes away on its own when I save or toggle source mode. The one before my paste location stays around, though. I do think I'm missing some subtle detail in the trigger conditions still, but I am not sure what it is. It seems to depend in some manner on what kind of blocks are before and after the insertion point, and yeah, the behavior varies browser to browser. I am reproducing this successfully in a Firefox Nightly with a brand new profile, so it's not extension related. It is not the 100% reproducible I was saying before though, which is interesting, so I'm starting to think there's something at play surrounding the type of blocks surrounding the paste position and the types of blocks in the content you're pasting. If I paste a single paragraph, I can at most get a single empty paragraph after the target position, and that only rarely. If I paste two <p> elements into an empty paragraph located between two existing <p> elements, I get empty paragraphs before and after the pasted content. If I paste two <p> elements at the start of an existing paragraph -- instead of inserting an empty paragraph and pasting there -- an empty paragraph appears before the pasted text, but *not* after it. If I paste two <p> elements at the end of an existing paragraph, an empty paragraph appears after but not before the pasted text.

I just successfully reproduced this again. I mention it since Kadir asked me to check on it yesterday. It is 100% reproducible.

All I did was this:

  1. Started writing a new page
  2. Wrote assorted content as usual
  3. Got near the bottom and decided as usual that instead of hand-writing the specification, browser compat, and see also sections, I'd copy them from somewhere else.
  4. Opened the editor for the article at https://wiki.developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection$edit.
  5. Copied the spec and browser compatibility sections as well as the "See also" heading (but not the list below that) from it by selecting them and pressing Command-C. Note that you can also copy the content from within the same article as you're pasting into; it doesn't have to be form another page).
  6. Went to the very bottom of the article I was creating, made sure the cursor was on an empty line, and pressed Command-V to paste. (It doesn't actually matter if it's at the bottom. All that matters is that the cursor is on an empty line before pasting).
  7. At this point visually things look fine. But I clicked the "Source" button in the editor toolbar to switch to source mode and then again to switch back to the WYSIWYG edit mode. This triggers a re-render of the content by the editor.
  8. There is now a blank paragraph just before the newly-pasted "Specifications" heading. It shouldn't be there.

I've also confirmed this happens when pasting elsewhere in the document; it does not have to be at the end.

MDN Web Docs' bug reporting has now moved to GitHub. From now on, please file content bugs at https://github.com/mdn/sprints/issues/ and platform bugs at https://github.com/mdn/kuma/issues/.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.