| Nikerabbit | |
| Dec 10 2015, 10:28 AM |
| F3108968: Screen Shot 2015-12-16 at 3.54.40 pm.png | |
| Dec 16 2015, 10:28 AM |
| F3108957: Screen Shot 2015-12-16 at 3.47.30 pm.png | |
| Dec 16 2015, 10:28 AM |
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.
| Project | Branch | Lines +/- | Subject | |
|---|---|---|---|---|
| mediawiki/extensions/ContentTranslation | master | +102 -68 | Do not drop id-less draft sections |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Amire80 | T95655 CX Phase 2 deployment issues (tracking) | |||
| Open | None | T96003 Publishing and saving errors (tracking) | |||
| Resolved | Pginer-WMF | T104059 Failures with auto-save causes users data loss when translating (tracking) | |||
| Resolved | Nikerabbit | T121092 Multiple paragraphs in a section causes data loss on restoration |
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:
| Browser | Inserts |
| IE | p |
| Google Chrome | div |
| Firefox | br |
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
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.