Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#1,327 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@efegokdemir ci sta già lavorando.

Dal 6/10/2026.

  • #1328 di @efegokdemir — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
38/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
developer-experience

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
TypeScript
Stelle
237
Fork
100
Merge medio
18h 10m
PR unite (30g)
16

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Shopify/theme-tools

Tutte le issue di Shopify/theme-tools

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.