Netlify-cms: Invalid markdown generated when applying styling to a selection with leading or trailing whitespace

Created on 18 Jun 2018  路  4Comments  路  Source: netlify/netlify-cms

- Do you want to request a feature or report a bug?

bug

- What is the current behavior?

When applying bold or italics to a selection that includes leading or trailing whitespace, the resulting markdown will put the space inside the **/_ delimiters. This means that the delimiter isn't a
left/right flanking delimiter run, and thus markdown compilers will render the emphasis characters literally.

- If the current behavior is a bug, please provide the steps to reproduce.

  1. Enter foo bar quux in a markdown widget.
  2. Select bar including the space after:

screen shot 2018-06-18 at 10 06 36

  1. Click the Bold button:

screen shot 2018-06-18 at 10 06 49

  1. Switch to markdown mode:

screen shot 2018-06-18 at 10 06 57

Observe that the rendered markdown is invalid (or rather, that it doesn't specify the bold text correctly). This can be verified using the commonmark.js demo or the markdown-it demo, for example.

- What is the expected behavior?

That the bold text in the markdown does not include the space: foo **bar** quux.

A more advanced variant of the bug can be created without ever having leading/trailing whitespace in a selection:

  1. Enter the text foo bar quux baz
  2. Select bar quux
  3. Click the bold button
  4. Delete quux (including the following whitespace) via the keyboard
  5. Switch to markdown mode.

This produces foo **bar **baz, which should have been foo **bar** baz.

Turns out this happens a lot in practice when editing the sort of content that we manage via netlify-cms.

- Please mention your versions where applicable.

Netlify CMS version: 1.9.2
Browser version: Chrome 67.0.3396.87/OSX

Node.JS version: 10.4.1
Operating System: Mac OSX 10.13.5 (High Sierra)

extensionwidgetmarkdown claimed intermediate bug confirmed

Most helpful comment

Has anyone found a workaround for this issue?

All 4 comments

Has anyone found a workaround for this issue?

@robertgonzales, I've attempted a fix, PR here: #1517. Would be great if you could take it for a spin!

I've tested this behaviour on the lates master branch and looks like this issue not relavent now:

Screen Shot 2019-10-03 at 21 44 50
Screen Shot 2019-10-03 at 21 44 58
Screen Shot 2019-10-03 at 21 45 03

Yes, the fix was landed and included in 2.4.0. I'll close this.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

chriskirknielsen picture chriskirknielsen  路  3Comments

bkroggel picture bkroggel  路  3Comments

ghost picture ghost  路  3Comments

Narno picture Narno  路  3Comments

TomPichaud picture TomPichaud  路  3Comments