Formatação de texto "pré-formatado" em linha usada quando a seleção de várias linhas não contém quebra de linha

Bug
1

Priority/Severity:

Medium

Platform

Operating System

Windows 11

Browser

Google Chrome 141.0.7390.123

Discourse

ad36231adab58a8a249bfe8139aade2bde2134d3

Description:

There are two styles of “preformatted text” formatting:

  • inline: for use with non-prose content within a prose passage (e.g., “call the foo function”), or a single short line of non-prose content.
  • block: for use with multiple lines of non-prose content

The user may take either of two approaches to applying formatting when using the composer:

  • proactive: the formatting mode is toggled prior to adding the content to be formatted
  • retroactive: the content is added in unformatted form, then selected and formatting applied to that selection

:bug: Applying “preformatted text” formatting to a multi-line selection uses the inappropriate “inline” style under the following conditions:

  • Composer is in the “rich text editor” mode
  • Formatting is applied retroactively
  • A hard line break is not present in the selected content

This results in the post being difficult to read and the non-prose content being difficult to copy (a common requirement for shared code).

Reproducible steps:

  1. Open the composer.
  2. Place the editor mode switch in the “rich text editor” position.
  3. Type foo in the composer.
  4. Press the Shift+Enter keyboard shortcut to add a “soft break”.
  5. Type bar in the composer.
    :red_exclamation_mark: Do not add a line break.
  6. Press the Ctrl+Shift+Home keyboard shortcut to select all content from the end of line 2 to the start of the post.
  7. Click the </> button on the composer toolbar.

:bug: Each of the selected lines was formatted individually in the inline style:

foo
bar

The correct behavior would have been to put the content in a single code block:

foo
bar

Additional context

I chose the approach of manually inputting the content for the demo in order to avoid introducing the unnecessary complication of considering formatting that may be present in copied content depending on the source from which it is copied. However, the fault also occurs with pasted content and the conditions of content not containing a hard break will be more likely to occur with such content (since the user is likely to use Enter while typing, even if they didn’t actually want a hard break).

The fault does not occur if you use “Select All”/Ctrl+A to select the content.

The Markdown editor has the correct behavior of always placing the selected content in a code block when “preformatted text” formatting is applied retroactively to a multi-line selection.

I am able to reproduce the fault on try.discourse.org in “safe mode”.

Originally reported at Why did the Forum functions change? - #37 by sterretje - Website and Forum - Arduino Forum

2

It doesn’t seem to happen when selecting manually as well.

3

Hi @NateDhaliwal. What do you mean by “selecting manually”?

Are you referring to selecting by scraping with the mouse? If so, the fault does still occur with that selection method:

manual-select

Or with Shift arrow key? If so, the fault does still occur with that selection method:

manual-select2

4

I’m not sure about this, this was an intentional exception, because you still have a single paragraph with a line break in this case, and adding inline code mark should be possible in this situation.

We can even consider a change in this behavior, but it’s not really a bug. /cc @lindsey

OK, sorry, I hadn’t noticed this. I think it makes sense to keep both consistent, indeed.

1 curtida
5

Yes, being consistent across the rich text and Markdown modes makes sense to me.

1 curtida