Announcing the Stacks Editor Beta release!

Question

TL;DR: The Stacks Editor Beta release rolled out on July 5, 2022! To see what we've been working on, what we are working on, and what we plan to work on, check out the Stacks Editor repo on GitHub. The editor is still an opt-in feature, and there is currently no timeline for a network-wide deployment.

---

This question is no longer being monitored for new answers. If you have further bug reports or feature requests for the new Stacks Editor, please post them as new questions tagged stacks-editor.

---

Back in early 2021, we announced the launch of the Alpha version for a new Stacks Editor. The announcement post saw a lot of activity, and after a lot of work by our Stacks Team, we're ready to launch the Stacks Editor into its Beta version!

In the original announcement for the Alpha Version of the new editor, Catija highlighted some of the reasons why we needed to create a new editor, ranging from meeting our Teams users' needs to simplifying future dev work on the public sites (you can read more in the original announcement). We asked you to test it and provide feedback — and you did. The post gathered 110+ answers with bug reports, feature requests, and more general feedback provided by you.

The team worked hard to respond to your feedback, but after a while, public feedback from the team about what was being worked on slowed to a near halt. While the team was still working silently on the Stacks Editor during this time, they had to balance this work with other priorities on their plate. More importantly, though, and as I mentioned above, we ended up not updating you on where work on the editor was and where we were planning on going with it: this doesn't reflect well on us, and we apologize. We'll aim to be more proactive and frequent with communications on this going forward. This brings us to this post.

As Yaakov mentioned earlier in June, the Stacks Editor is the main editor used in the new Ask Question Wizard, which will be made available on Stack Overflow sometime after the Beta 2 release goes out. The new Wizard, in turn, will later be a central piece of the Staging Ground project. So where are we going next?

Roadmap

You can have a look at the Stacks Editor repo on GitHub to see a breakdown by feature of what's been worked on and what is still to come (issues in the “No Milestone” section are backlogged, with no projected pick-up date). To give you a high-level overview:

• Alpha 2: This is what the team's been silently building and shipping since the original Alpha release of the editor. The editors used on network sites were updated to include this release on June 21, 2022. The team’s worked to fix many of the issues reported by you, including:

  • some issues caused by flipping from the Markdown mode (MD) to the Rich Text (RT) mode, and back (examples here, here, and here);

  • issues with tooltips obscuring the editor area on mobile;

  • and Enter key oddities in Firefox.

• Beta 1: This was released on July 5, 2022 and is in production as of July 12. Full release notes are available. The main accomplishment of this release is to ensure the back-end library is feature-complete as compared to the old editor — meaning the Stacks team laid the groundwork that’ll allow the dev teams responsible for the Public Q&A sites to work on Stack Exchange-specific functionality. With this, the latter teams will be able in the future to build plugins into the editor, with the goal of reaching feature-parity (for all sites) to the old editor available on the network. Some of the issues addressed on this release were:

  • adding initial support for a Markdown preview pane — we know this was a big pain point for many of our power users. Happy to announce that preview mode is now available;

  • enhancements to link insertion and editing, as per the issues reported here and here;

  • triple-clicking selecting the whole text in Markdown mode;

  • and adding official external plugin support, which will be required for supporting various extra editor features across the Stack Exchange network, such as poker, go, chess, code snippets, and MathJax.

• Beta 2: This was released on July 28, 2022, and the editor was released on participating sites on August 8, 2022. For this release, we identified some issues we feel should be addressed before launching the Ask Wizard and Staging Ground projects. This release also included some issues that were reported in answers to this post. Some of the highlights for this release are (full release notes also available):

  • Improvements to code block indentations;

  • An overhaul to the code highlighting system that addresses a number of issues reported with highlights to Markdown mode when text isn’t CommonMark compliant, as reported here, here, and here.

  • A change in the toggle between Rich Text and MarkDown modes - the toggle is now icon-based, instead of the on-off switch that had been in place up until now.

  • Bug fixes with image-uploads (here and here), code block serialization.

  • Block elements are now allowed inside list items.

• Beta 3: These are issues that would be beneficial to address, but not required for baseline functionality. Once these are addressed, the Stacks Editor should be ready for a network-wide deployment (though we don’t currently have any plans to do that; more on that below). There isn’t a timeline for addressing these issues, and the team will tackle them as their bandwidth permits. Highlights for this release include:

  • adding the ability to change the code block language in Rich Text mode;

  • using a different resize anchor;

  • and some issues with line breaks in tables, that occur when switching from Markdown to Rich Text and back.

Until the end of July 2022, we have members of the Stacks team as well as devs from one of the teams responsible for Public Q&A assigned to working on the issues marked as essential for the Beta 2 release. Additionally, there’s some flexibility on that roadmap to account for high-priority issues reported in response to this post, and though we can’t guarantee we’ll be able to address every single thing reported, we’ll be responding to all feedback as we triage it and, all applicable unique issues will be logged in the Stacks-Editor repo. Once July’s over, we’ll still be monitoring and responding to issues and feature requests surrounding the Stacks editor, be them reported on MSO or MSE (which can be brought to staff attention using this process), or on GitHub (more on how to report issues at the bottom of the post). These will be triaged based on severity and developer availability to prioritize issues for the Beta 2 release.

FAQ

What was that about a network-wide deployment?

As I mentioned above, the Stacks Editor is a central piece of the new Ask Question Wizard and Staging Ground, so for now we’re committing resources to ensure the work needed to support that project is successful. Additionally, we’re expecting you will report many more issues that have yet to be identified, and have to be prepared to be able to address those issues and respond to those reports. For that reason, at the moment we don’t have any timeline to roll out the Stacks Editor network-wide, and are instead focusing on ensuring we can undertake the near term work required to support the Ask Question Wizard and Staging Ground project. When we get to the point where it looks like extending the opt-in testing to questions, or even a network-wide deployment might be in sight, we’ll make sure to loop you in.

Is this still opt-in?

Yes! The editor will continue to be available on Stack Overflow for Teams, and for answering questions on Meta Stack Overflow and Meta Stack Exchange — this is reached via an opt-in on the Profile > Settings page labeled “Enable new editor” (the text here will be updated soon to change the “Alpha” label into a “Beta” label). When the Ask Wizard is released on Stack Overflow, all users will be able to toggle into this question asking mode, where they’ll be able to try out the Editor in that context as well (more details around this will be shared on MSO when the release is made).

How to provide feedback

We will be monitoring this post for responses until the end of July 2022. If you have feedback, bugs to report, or feature requests, please post them as an answer under this question — with one issue per answer. Please make sure what you’re posting here hasn’t been posted already, and do not report issues in comments. Please provide steps needed to reliably reproduce a bug, along with which browser/s you're experiencing the bug in. If an issue on the Alpha Release post doesn't have a link to an active case on GitHub (GH) feel free to repost here and link to the original in the report. If it does have a link to an active case it is being worked on so there is no need to repost here. Additionally, since this is an open-source project, you can also use the GitHub repo for the editor to submit new issues if you feel comfortable doing so — we'll cross-link stuff reported here and in the GH repo. As mentioned above, you can also use the repo to check out the issues still scheduled for work. After July 2022, issues should be reported as separate questions tagged stacks-editor.

Answer 1

bug status-review GH #185

Using the Markdown editor, if you try to quote a table the leading pipes are removed on all lines except the separator row. First click:

> 
> Column A | Column B |
> | -------- | -------- |
> Cell 1   | Cell 2   |
> Cell 3   | Cell 4   |
> 

If next you try to unquote the greater than > quote character isn't removed from the separator row. Further clicks of the quote button will repeat the process, adding more quote characters to the separator row. After 7 clicks:

> 
> Column A | Column B |
> > > > | -------- | -------- |
> Cell 1   | Cell 2   |
> Cell 3   | Cell 4   |
> 

GIF for reference

Answer 2

bug status-review GH #70

Let’s say you wanted to quote a source fence. If you press the quote button, having the source fence selected, it has a double effect:

• It keeps adding quotes on the triple backtick lines ```;
• It adds and removes the quotes on the remaining lines.

The result after six clicks looks like this:

> 
> > > ```
> some text
> > > ```

Answer 3

Cursor disappears in long posts

bug ios status-review GH #206

(Reposting from Can't use Stacks editor for long posts on iOS because the cursor disappears because there is no GitHub issue yet.)

This is really a serious bug. When I try to edit text towards the end of a long post (or sometimes middle, for very long posts), my cursor disappears. Where exactly this happens seems to depend on where the scroll bar is.

I can't see where I'm typing except that text appears (or disappears, when backspacing), and trying to move around my cursor is hopeless because tapping doesn't make it appear and neither does holding the spacebar. I can't see if I have any text selected either (as I sometimes end up deleting the entire body of the post). Examples of a few answers where this happened:

• What are "Community Wiki" posts?
• Allow 'improve' for Tag Wiki Edit Suggestions
• New tags page mangles tag wiki excerpts
• ‘Remove wiki’ showing when a question is not a wiki
• My answer about tables and accessibility, which isn't even that long or complicated.
• Another answer of mine, which only uses bullets and a horizontal rule for formatting and also isn't really that long
• This answer (can't edit the last paragraph or below that at all, can only sometimes see my cursor in the paragraph above that; nothing below the image has a cursor in WYSIWYG mode)
• The accepted answer on this question where I'm supposed to add a link to this answer

Cursor is between community and the period when I was backspacing:

I tested it on two different browsers (iOS Chrome and iOS Safari) on different devices and it happens on both. It also happens on the preview editor. (I have not encountered this on desktop, which is the device I have to switch to in order to make edits.) It doesn't happen on every answer, only when the answer is long or maybe has some complicated formatting. It also seems to happen in both editor modes.

Significantly, this is preventing me from editing something on a private Team (where this is the only editor, and I also see this happening on questions), so it should be fixed.

Answer 4

bug status-completed GH #21

Headings created by dashes or equal signs under the line are only shown as headings in Markdown mode if there are at least two such characters

The rich-text mode previews this as a heading, regardless of the number of such characters. This is the correct behavior, per the relevant section of the CommonMark spec.

Note that no editing is required in the above demonstration of this bug, as toggling Markdown mode collapses the heading underline into a single character (thus greatly increasing the likelihood of this bug being hit).

Answer 5

bug status-planned

When I went to edit my answer on MSO. When in preview mode (not markdown) the bare links in a list were prefixed with a loading spinner.

Toggling between markdown and back does not resolve this:

I let it spin for 12 minutes so it doesn't seem like it is going to resolve. (It also doesn't look like any type of request was made to be resolved?) If this is supposed to indicate that these links will be changed when submitted we should really have a different indicator than a loading spinner.

This only seems to impact bare links in lists.

Here's another example:

Removing the list removes the spinner. Putting the list back restores the spinner (whether the lists are restored through markdown or with the UI):

Some more answers which show loading spinners on MSO:

• https://meta.stackoverflow.com/a/296145/15497888
• https://meta.stackoverflow.com/a/288152/15497888
• https://meta.stackoverflow.com/a/333519/15497888

---

Curiously, I was unable to reproduce this in a new answer on MSE (nor in this answer itself):

Either on the initial post:

Or on an edit after:

Answer 6

bug status-review GH #189

When trying to delete multiple tables in the rich text view, only one table is deleted at a time.

Here's a GIF demonstrating the deletion of multiple tables at once (using manual selection):

Using Ctrl+A to delete all the tables works.

If there is text above the first table, then all the tables can be deleted at the same time, as intended:

---

Also reported in this answer to Opt-in alpha test for a new Stacks editor.

Answer 7

bug status-review GH #191

Pressing the down arrow key in a code block with multiple lines moves out of the code block, instead of down to the next line in the code block:

In this video I pressed these keys: Down Up Up

Answer 8

bug status-planned GH #201

As I asked here, tag markdown displays differently in Stacks Editor than it does in Meta SO:

When I typed [tag:*-faq] in the new stacks editor, it rendered as a tag (like asterisk-faq), but then when I posted my answer, the unrendered Markdown was displayed.

Further, the Markdown following the asterisk was also italic.

Screenshot showing Stacks editor Markdown:

Screenshot showing Stacks editor rendered Markdown:

Screenshot showing how Markdown was rendered on Meta SO:

Answer 9

feature-request status-review

Allow saving edits to a post using Ctrl+Enter, like in the old editor.

Users used to using Ctrl+Enter would be quite annoyed every time a newline is entered instead...

---

Also requested in this answer to Opt-in alpha test for a new Stacks editor.

Answer 10

bug status-completed GH #21

Preview does not support lang-* notation for syntax highlighting specification:

However all highlight correctly when it is posted:

print('test')

print('test')

System.out.println("test");

System.out.println("test");

Answer 11

bug status-completed GH #202

When editing an answer on mobile, and opening the image uploader there isn't enough room for all contents:

Answer 12

bug status-completed GH #152

Switching from Markdown to rich text mode strips blank lines in a variety of cases. For example writing this in Markdown mode:

<!-- some HTML comment -->

paragraph

has the empty line stripped when switching to rich text mode:

<!-- some HTML comment -->
paragraph

According to CommonMark specification blank lines don't break blocks, so the editor should keep blank lines when switching modes because the users may want to use them to visually break walls of text in the source.

Answer 13

bug status-review GH #192

Inserting a horizontal rule in Markdown mode makes the previous line a header

Dashes under a line in Markdown apply header formatting. There needs to be a blank line between the text and the row of dashes. The existing editor handles this correctly.

Also, minor related note: toggling between Markdown mode and regular mode changes the number of dashes from three to one (not a meaningful change).

Answer 14

bug status-review GH #194

Various oddities occur when a numbered item is a child of a bulleted item

This is based on the following Markdown:

- Bulleted item
  1. Numbered item

The following problems occur:

1. Selecting the bulleted item and pressing the bullet button does nothing. This may or may not be expected. status-bydesign
2. Selecting the numbered item shows both the bullet button and the number button selected. This may or may not be expected, as it is technically within a bulleted item status-review. Pressing the number button removes the number, as expected.
3. Unexpectedly, pressing the bullet button also removes the number. Pressing it a second time removes it from the parent bulleted item, as expected. status-review
4. The first bullet cannot be backspaced. Doing so with something else before the bullet (not shown in this video) causes the cursor to move to that. This may or may not be expected, as it's somewhat unclear what should happen to the child when the parent bullet is removed. status-bydesign However, if it is not the first item in the bulleted list, then the bullet can be backspaced. The behavior should be consistent. status-bydesign
5. Backspacing the bullet in this scenario results in the rich-text editor showing the formerly bulleted item's text indented until Markdown mode is toggled on and off, at which point it is no longer indented. status-bydesign

Answer 15

bug

Undo/Redo buttons don't always work

I guess this could be considered one bug or two, but I'm just reporting it once.

In the editor currently on SE, switching modes destroys the undo/redo stack.

status-declined

I can undo and redo changes in the mode I used to make them, but switching to the other mode resets the undo/redo stack so pressing the undo/redo buttons do nothing.

For example, you type some text in markdown mode and undo and redo work. The second you flip the switch to preview mode, pressing undo and redo no longer do anything. If you type more now, you can undo to what it looked like when you switched but not before that.

GIF for reference

In the most up to date editor, the undo/redo buttons do nothing

They just don't work.

There is an issue with undo/redo on the demo editor, but it works fine on the site. — Yaakov Ellis

---

Reproduced in iOS Chrome, Windows 11 Chrome, MacOS Chrome. Leave a comment if you can reproduce elsewhere. Note that you will need to be in "narrow mode" to see the undo/redo buttons.

Answer 16

bug

Applying a [numbered / bulleted] list to multiple lines works differently in each mode

---

Steps to reproduce:

1. Type text on multiple lines with single line breaks.
2. Select all lines.
3. Apply [Numbered / Bulleted] list to the selected text in Markdown mode.
4. Repeat using double line breaks.
5. Repeat the above in rich text mode.
6. Observe the difference.

---

GIFs for reference:

1. Single line break applied:

   

2. Double line break applied:

   

---

What's happening in Markdown mode?

• After selecting and applying a numbered list, the numbers assigned to each line are the same. Switching to rich text [and back to Markdown] fixes the numbering. This is not a bug, as Marijn notes below, but it would be nice to have it apply the proper numbering in the first go itself.

• Compared to rich text mode (and the old editor), the numbering is applied to all the lines. In the case of bulleted lists, the bullet points are also applied to all the lines in Markdown mode.

• In the case of double line breaks, the [numbers / bullet points] are applied to blank spaces as well (as shown in the GIF above).

What's happening in rich text mode?

• After selecting all the lines, with either single or double line breaks, and applying a numbered list in rich text mode, the numbering is only applied to the first item in the list, as is the case in the old editor. This is also the case with bulleted lists.

---

Comparison with the old editor

Answer 17

feature-request status-review

Either the help icon shouldn't direct you to Markdown help in rich text mode, or the help page should mention both Markdown and rich text.

Answer 18

bug status-review GH #207

When translating a combination of p tag element and HTML comment on the MD mode, RT mode display transcribes texts weirdly:

• Overlap with the placeholder text
• Wrap in a blue border box
• Uneditable. Inserting new words make the whole text deleted.

In MD mode, insert this:

<p>A paragraph.</p>
<!--This is a comment -->

Result in RT mode:

Even back to the MD mode and deleting the HTML comment, the issue is still remaining.

Expect: Having a HTML comment shouldn't affect displaying the text in RT mode.

Answer 19

bug status-bydesign

Not sure if this is intended or not, but only one spoiler can be revealed at a time in the rich text view:

This does not happen after posting the answer.

Test:

I can

see

multiple spoilers

at the same time

but only after

posting the answer

---

Compare with the old editor (it's possible to see all the spoilers at the same time in the preview itself):

Answer 20

feature-request status-planned GH #101

Make the resize tool more (visually) accessible.

In the new editor, the resize tool is denoted by two small diagonal lines in the bottom right corner of the editor:

This can be quite easy to miss. For users using the non-inline edit screen, in some cases, the resize tool (for resizing to see more of the question) is barely visible:

---

In the old editor, the resize tool is more visible:

---

Related to this answer to Opt-in alpha test for a new Stacks editor.

Answer 21

bug status-review GH #195

In rich text mode having an HTML comment at the top of a post causes the editor to display a blue horizontal bar -if you move the cursor on that line in the editor- for example:

<!-- some HTML comment -->
paragraph

Causes the blue bar:

This shouldn't happen since a comment shouldn't cause a visual queue in the editor?!

Answer 22

bug status-review GH #196

Adding a link to text with a space at the end causes the space to be included in the link text

This can happen, for instance, when you double-click a word to select it. The old editor handles this correctly, trimming the portion that gets the link applied to not have any whitespace at the end.

Answer 23

bug status-review GH #198

In rich text mode a horizontal rule, <hr>, does not have a selection highlight whereas surrounding paragraphs have it. (This can be compared to this report where an HTML comment does have a selection highlight.)

Answer 24

bug status-completed GH #193

In rich text mode if you click to edit and cancel a link the tool is left at the bottom and doesn't reset its position back to under the link. Steps to reproduce:

1. Click Edit link

2. Next click Cancel

3. The link edit tool didn't reset its position back to underneath the link where the cursor is; it's left dangling where the previously expanded tool dialog ended.

GIF for reference:

---

System specific info: Firefox 102.0.1 (64-bit) on Windows 10. Rev at the time that I originally posted this.

Answer 25

feature-requeststatus-declined

It would be nice if in rich text the language code shown in the upper right corner of a source fence could be correctly stylized as Python, CSS, JavaScript instead of python, css, javascript, etc...

I know the tags are all lower case but I haven't found a post with explicit rules about casing because apparently writing Python instead of python in the language code of the source fence works all the same. But writing Python in sentence case still makes the language code show in lower case in the editor.

Answer 26

bug status-bydesign

Bolded message in Markdown is already bolded.

Shouldn't it be unbolded when in Markdown?

Answer 27

bug status-review GH #197

This bug is the opposite of GitHub issue#41.

In rich text mode, if the first element in a post is a source fence, there's no way to insert a blank line before it, anything you type gets inserted inside the fence. (The proposed Shift + Enter workaround escapes the fence downward but not upward.)

I consider this a breaking bug since the only obvious workaround for rich text users is deleting the entire fence to be able to insert something else at the beginning of the post.

Answer 28

bug status-review GH #199

In rich text mode, having an horizontal rule after a source fence, if you move the cursor down ↓ it visually pushes the <hr> down one line each time you go over it. Start like this:

```
text in fence
```
---

After passing the cursor over the <hr> twice by pressing ↓ here's a picture of the horizontal rule having moved 2 lines, if you switch to Markdown no blank lines were introduced.

Answer 29

bug status-review GH #200

In rich text mode, when selecting a link and moving upwards, the link dialogue is also moved up vertically to under blocks that aren't links.

Start like this:

Then move up:

GIF for reference

Answer 30

bug status-completed

When uploading an image the license is written in small case cc by-sa but for consistent styling with the rest of SE it should be capitalized as CC BY-SA.

I've written a previous post about the same bug in the footer cc by-sa in footer should be capitalized