Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sanity Studio Rich Text Editor does not properly close 3rd level ordered list tags #6879

Closed
slegay opened this issue Jun 7, 2024 · 4 comments

Comments

@slegay
Copy link

slegay commented Jun 7, 2024

If you find a security vulnerability, do NOT open an issue. Email [email protected] instead.

Describe the bug

When writing nested ordered lists, if a sub-list ends with a 3rd degree tabbed list, the next number is wrong. It seems that an ol tag is not getting properly closed.

To Reproduce

Create this ordered list in Sanity portable text editor editor, as shown in the screenshot.

image

Expected behavior

c should be a

Screenshots

image

Which versions of Sanity are you using?

@sanity/cli (global) 3.45.0 (up to date)
@sanity/dashboard 3.1.6 (up to date)
@sanity/google-maps-input 4.0.1 (up to date)
@sanity/ui 2.3.1 (up to date)
@sanity/uuid 3.0.2 (up to date)
@sanity/vision 3.45.0 (up to date)
sanity 3.45.0 (up to date)

What operating system are you using?

Ubuntu

Which versions of Node.js / npm are you running?

9.8.1
v18.18.2

Additional context

The problem goes away when adding a level 2 item after finishing a level 3 ordered list, and before starting a new level 1 list item, as shown below:

image

@joelschneider
Copy link

+1

The issue is even broader I believe.

If you have more than one simple ordered list in a portable text editor, the following ordered lists continue the numbering from the previous ordered list.

Example:

  1. ...
  2. ...
  3. ...

[Other content]

  1. ...
  2. ...

Very annoying tbh, as this renders this basic functionality useless if you have more than one ordered list in an article.

@christianhg
Copy link
Member

Hi there! Just want to let you all know that the problem that @joelschneider describes should be fixed by v3.53.0. Related PR: #7286

However, the problem described in the OP is not fixed yet. It's in our backlog though!

@christianhg
Copy link
Member

This problem has now been fixed in #7506. Thanks again @phattran2905 !

Copy link
Contributor

This thread has been automatically locked because it has not had recent activity. Please open a new issue for related bugs and link to relevant comments in this thread.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 18, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants