Page MenuHomePhabricator

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

Description

I am able to reproduce the report in https://de.wikipedia.org/wiki/Benutzer_Diskussion:Jensbest#Testing_saving_failures_for_Content_Translation

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

https://gerrit.wikimedia.org/r/258170

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

BrowserInserts
IEp
Google Chromediv
Firefoxbr

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.

HTML

<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.
HTML

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

third

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

https://gerrit.wikimedia.org/r/258170

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.

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

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.