Page MenuHomePhabricator

Multiple paragraphs in a section causes data loss on restoration
Closed, ResolvedPublic


I am able to reproduce the report in

Using enter at the end or in middle of translation section causes all data below the line break to be lost on restore. On further resting the problem seems to happen on restore, the original data to be saved is sent correctly and in whole.

Event Timeline

Nikerabbit claimed this task.
Nikerabbit raised the priority of this task from to High.
Nikerabbit updated the task description. (Show Details)
Nikerabbit added a subscriber: Nikerabbit.

Change 258170 had a related patch set uploaded (by Nikerabbit):
Do not drop id-less draft sections

When enter key is pressed inside a content editable, browser behavior differs:

Google Chromediv

This bug happens if the inserted tag is a section tag. ie p or div. If you do this in Firefox, restoring works fine since it is an br inside paragraph,

Your patch handles the cases of section tags correctly. I tested.

But, having a <div> tag in HTML causes Parsoid to insert the <div> tag in the generated wiki text. And the article published will not have that paragraph break. So the users intention of paragraph break is not accompilished.


<p>first <div>second </div></p>

Wikitext generated:

first <div>second </div>

If the br tag appears inside the HTML , generated wiki text will have paragraph breaks and hence it satisfies users intention.

<p>first <br>second<br><br>third</p>


So I am wondering whether we should let <br> tags generated like FF does(there wont be new sections and hence no restore issue) for all browsers consistantly

Ideally, on enter keys, we should close the <p> and insert a new <p> by disallowing both div, and br creation inside <p> tag

Change 258170 merged by jenkins-bot:
Do not drop id-less draft sections

On Chrome (see image below), unusually big line breaks appear even if only one line break was inserted (using the Enter key), and these breaks are not editable.

Screen Shot 2015-12-16 at 3.47.30 pm.png (507×803 px, 120 KB)

In Firefox (image below), the line breaks displayed are consistent with inputs and also editable.

Screen Shot 2015-12-16 at 3.54.40 pm.png (549×821 px, 129 KB)

The above results are consistent with @santhosh's comments in the ticket. While the restoration works fine and the original complaint is gone, the inconsistent browser behaviour is annoying and in case of Chrome pretty disruptive.