Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#1,327 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@efegokdemir がすでに取り組んでいます。

2026年10月6日 から。

  • #1328 @efegokdemir による — オープン

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
38/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
typescript
領域
developer-experience

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
TypeScript
スター
239
フォーク
104
平均マージ
1日 2時間
マージ済み PR（30日）
23

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Shopify/theme-tools のほかの issue

Shopify/theme-tools の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。