Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

HTML close-tag auto-insertion (`onTypeFormatting` on `>`) closes the wrong element

Abierto
  • ¿Algo no está bien?
#1,327 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@efegokdemir ya está trabajando en esto.

Desde el 6/10/2026.

  • #1328 de @efegokdemir — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
38/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
typescript
Área
developer-experience

Línea de trabajo

Start from HtmlElementAutoclosingOnTypeFormattingProvider, which handles textDocument/onTypeFormatting with ch >; reproduce with the <ul>\n <li>\n</ul> snippet and trace how the element lookup behaves when the tree parses into an error node. Read the earlier fix from PR #516 for context on Liquid branches. Note a linked open PR (#1328) already targets this issue, so check its status before starting; done means the response inserts </li> for the just-opened element in the error-state document.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Describe the bug
When I type > to finish an opening tag, the language server's textDocument/onTypeFormatting response inserts the closing tag of the parent element instead of the element I just opened. In my case the parent's closing tag already exists later in the document (the usual situation when adding a child to existing markup). I noticed it in Zed, but the wrong text comes from the server's response (see "Additional context").

Source

<ul>
  
</ul>

Steps: on the empty line, type <li>. The cursor is right after the >.

Expected behaviour
</li> is inserted after the cursor.

Actual behaviour
</ul> is inserted:

<ul>
  <li></ul>
</ul>

The server then reports Attempting to close HtmlElement 'ul' before HtmlElement 'li' was closed on the inserted text.

Debugging information

  • OS: Mac
  • OS Version: 27.0.1
  • Theme Check Version: n/a, I'm using the language server through the Zed Liquid extension, version 0.7.0
  • Editor: Zed 1.22.0

Additional context
LSP trace. The trace below comes from a larger file (header.liquid), so the line and character numbers differ from the snippet above. The document at the time of the request (unclosed <li> followed by the existing </ul>):

<ul>
  <li>
</ul>

Request:

{"jsonrpc":"2.0","id":46,"method":"textDocument/onTypeFormatting","params":{"textDocument":{"uri":"file:///.../header.liquid"},"position":{"line":17,"character":10},"ch":">","options":{"tabSize":2,"insertSpaces":true,"trimTrailingWhitespace":true,"insertFinalNewline":true,"trimFinalNewlines":true}}}

Response:

{"jsonrpc":"2.0","id":46,"result":[{"range":{"start":{"line":17,"character":10},"end":{"line":17,"character":10}},"newText":"</ul>"}]}

The position (line 17, character 10) is immediately after the > of <li>, so the request is well-formed. I reproduced it on two separate captures with the same result.

My guess, which may be wrong: at the time of the request the document doesn't parse, because <li> is unclosed before </ul> (the server reports a parse error for this document). The element lookup in HtmlElementAutoclosingOnTypeFormattingProvider seems to land on the parent when the tree is in that error state.

This looks related to the earlier fix "Fix HTML element close tag auto-insertion inside Liquid branches (#516)", but my case has no Liquid branches, only plain HTML.

Workaround: in Zed, setting "use_on_type_format": false for the HTML language stops the behavior. That confirms the insertion comes from this request. Inside a Liquid file, Zed treats the language at the cursor as HTML, so that setting applies there. Other features (completions, diagnostics, hover) work normally.

Lenguaje dominante
TypeScript
Estrellas
237
Forks
100
Merge medio
18 h 10 min
PR fusionados (30 d)
16

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Shopify/theme-tools

Todos los issues de Shopify/theme-tools

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.