Page MenuHomePhabricator

<br> stripped by VisualEditor
Open, Needs TriagePublicBUG REPORT

Description

What is the problem?

Line breaks (<br>) are not being preserved by the VisualEditor on wish submission.

I experimented with the VisualEditor on other pages and in those cases line breaks are preserved.

Steps to reproduce problem
  1. https://wishlist-test.toolforge.org/wiki/Community_Wishlist/Intake
  2. In Describe your wish, with Source Editor enabled, enter
Line 1<br/>
Line 2<br/>
Line 3<br/>
Line 4<br/>
Line 5<br/>
Line 6<br/>
Line 7<br/>
Line 8<br/>
  1. Switch to VisualEditor
  2. Fill out the rest of the form and submit

Expected behaviour: On the wish page, each Line # should appear on a separate line. If you view the source of the wish you just created, in the problem section of the template, the wikitext should be the same as you entered (including all the <br/>)
Observed behaviour: The description appears as one line.

Environment

Browser: Firefox 115
Wiki(s): https://wishlist-test.toolforge.org

Screenshots

Before submitting the wish, showing the line breaks:

ve_brs.png (365×986 px, 18 KB)

Line breaks have not been saved:

ve_brs_page.png (375×998 px, 26 KB)

Event Timeline

TheresNoTime subscribed.

Really janky example given that none of the templates etc. are present on test.wiki, but bear with me — this issue is not reproducible when the gadget is loaded in production. A different issue does exist though.

This proposal (if you can call it that!) was created with the form. If you view the wikitext which was generated from the below content, you'll note that a single return equates to two line breaks in the wikitext (rendering as a line break).

Example content used in form

test
test
test
[...etc...]

Wikitext generated

test

test

test

[...etc...]

Form content retrieved

(Content which was retrieved and placed in the description field of the form when editing the proposal, which is potentially incorrect/unexpected behaviour)

test

test

test

[...etc...]

edit: The retrieved content seems to be caused by the description field defaulting to source editing (within the VE interface) — switching back to visual editing resolves the issue

@TheresNoTime it looks like this has been in development since July 9. Is there anything at this stage that's a blocker? How high of a priority is this bug?

@TheresNoTime it looks like this has been in development since July 9. Is there anything at this stage that's a blocker? How high of a priority is this bug?

This became a VE bug iirc, and isn't as high a priority given its not reproducible in production — I'll "unlick" this task.