Repository navigation
[BUGFIX lts] Reset tracking when the cleanup of a render error throws - #21685
Conversation
564f6e2 to
9203d38
Compare
| let element = document.createElement('div'); | ||
| let marker = document.createComment('marker'); | ||
|
|
||
| element.append(marker); |
There was a problem hiding this comment.
NOTE that I don't think this is supported behavior -- but if something does this, I suspect that unless we fully understand why, we just move when the error occurs
(such as those automated translation tools browsers sometimes use)
There was a problem hiding this comment.
per the reported issue, it is simulating a bad behavior from a modifier in a test
9203d38 to
58a36db
Compare
|
The fix is inside
The run therefore compares identical code, and it shows the noise of the benchmark.
The three script time hits are How this was measured
|
58a36db to
23b6117
Compare
23b6117 to
12f57d8
Compare
…rows In a development build, `VM.execute` closes the open blocks after a render error, and then calls `resetTracking()`. `popBlock()` throws when the DOM of a block is gone. That error left the `finally` block before `resetTracking()` ran. The tracking frame then stayed open, and each later tracked write failed with a backtracking assertion. The reset now runs in a `finally` block around the `popBlock()` loop. Fixes emberjs#21681 Co-Authored-By: Alberto Cantú Gómez <9092644+betocantu93@users.noreply.github.com> Co-Authored-By: Geoff Hodgson <208148+geoffroh@users.noreply.github.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
12f57d8 to
482321a
Compare
… new §05-14 item 15) Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Fixes #21681
A render error in a development build can leave the tracking frame open. Each later tracked write then fails with a backtracking assertion, in every later test.
Cause
VM.executecleans up after a render error in this order:popBlock().resetTracking().popBlock()throws when the DOM of a block is gone. That error leaves thefinallyblock, and step 2 does not run.Fix
The
popBlock()loop is now in its owntry, andresetTracking()runs in thefinallyof thattry.Test
render-error-cleanup-test.gjsrenders into a stale cursor: thenextSiblingof the cursor is no longer in the element.The render fails at its first insert with a
NotFoundError. The VM then fails again when it closes the open block. The test has no custom throw and no DOM change during the render.mainisTracking()istrueA real modifier error does not reach this path on
main. A modifier throws during the commit, afterVM.executereturns. I ran three sequences with{{on "click" undefined}}followed by more renders into the same element, and none left a tracking frame open. On 7.3.0, the reporter got to the same VM state throughclearRender(), which cleared the element under a failed root.Not in this PR
renderComponentcreates is not a destroyable child of the owner when the first render throws. The issue reports this as a separate leak.Relation to #21634
The two PRs fix different holes. #21634 makes the reset run in production builds. This PR makes the reset run when
popBlock()throws.I ran the test file from #21634 on this branch and on
main.GlimmerishComponentis gone frommain, so I used@glimmer/componentin its place.mainThis PR does not change those results. The test in this PR needs a development build, and #21634 keeps the
popBlock()loop before the reset with notry.🤖 Generated with Claude Code