Implement error interception during refreshView and provide onError callback options in ViewContainerRef for programmatic rendering and encapsulation of boundary errors.
PR Close#70463
This started from a real production crash trace:
TypeError: Cannot read properties of null (reading 'nextSibling')
Traced through a minified bundle back to siblingAfter() in
packages/core/src/hydration/node_lookup_utils.ts. It walks forward a
fixed number of DOM siblings during hydration, based on how many the
server rendered. Its only guard, validateSiblingNodeExists(), is
gated behind ngDevMode and stripped from production builds. If the
client DOM has fewer real siblings than the server-serialized data
expects — client/server render diverged, or something outside
Angular (a browser extension, an injected script) removed a node —
the loop ran fully unguarded in production: currentNode went null
partway through, and the next iteration's currentNode.nextSibling
threw a raw, uncoded TypeError instead of a coded, debuggable one.
Reproduced first, not just theorized: added a test that server-
renders a @for loop with 3 items, removes 2 of them before hydration
runs, and confirmed it actually throws that exact TypeError against
the original code before touching anything.
Fix: add a null check at the top of the loop, matching the pattern
already used for the existing NG0500/NG0502 hydration checks in
element.ts — the dev-mode check runs first as before (a no-op in
production), and the new check is a pure safety net that only fires
once that dev-mode check has already been compiled away. In dev mode
this is provably dead code, so nothing about dev behavior changes.
Coded as NG0501 (HYDRATION_MISSING_SIBLINGS, already existed).
While investigating, found and fixed two more call sites with the
exact same shape of bug — a dev-only check that leaves production
completely unguarded:
- navigateToNode() (same file): walks an explicit "firstChild /
nextSibling" navigation path recorded for nodes that can't rely on
simple sibling-walking (e.g. content right after an <ng-content>
slot). Its only guard was also ngDevMode-only. Added the same
production safety net, both mid-loop (the raw-crash case) and
post-loop (where it could previously return null silently despite
the function's return type promising a non-null RNode). New code:
NG0509 (HYDRATION_MISSING_NODE_ON_PATH).
- getParentRElement() (render3/node_manipulation.ts): typed its
tNode parameter as always non-null, but a real production trace
showed it can be null at runtime, crashing on tNode.parent with no
useful information. Widened the type to TNode | null and added a
guard that throws a coded error instead. New code: NG0510
(PARENT_NODE_NOT_FOUND).
Unlike the other two, this one isn't gated behind ngDevMode at all
in the original code — it reproduces unconditionally. Decoded the
actual production minified stack trace against this source
(matched every frame character-for-character) to find the real
cause instead of guessing: an @if/@switch branch's content is its
own embedded template with its own TView, built lazily the first
time that branch renders. If an error interrupts that first pass —
here, a hydration mismatch on the branch's second child, after the
first child's TNode was already created — TView.firstCreatePass
still gets flipped to false in render.ts's `catch` block before the
error propagates, permanently marking that TView as corrupted.
Unlike a component's TView (rebuilt from scratch next time via
getOrCreateComponentTView()'s incompleteFirstPass check), nothing
rebuilds an embedded view's TView. The next time that exact branch
is selected again, its instructions read straight from the
corrupted tView.data instead of creating a fresh TNode, and any
node past the interruption point is still null.
The real test added for this (full_app_hydration_spec.ts) exercises
that whole chain for real: a hydration mismatch on an @if branch's
second child, then re-entering the same branch. Confirmed it throws
the exact byte-for-byte production error message ("Cannot read
properties of null (reading 'parent')") without the fix, and the
coded NG0510 with it. This replaces an earlier synthetic unit test
that just cast a variable to null to bypass the type system rather
than reproducing the actual failure.
Note: a more thorough fix would rebuild the corrupted embedded TView
itself (mirroring getOrCreateComponentTView()), which does make the
crash disappear — but doing that surfaces a second, separate bug:
the aborted first attempt's partially-created LView/DOM is never
torn down, so the retried branch's content gets appended alongside
leftover orphaned nodes instead of replacing them, corrupting
content silently instead of crashing loudly. That's a materially
bigger fix (proper LView cleanup after a mid-creation exception) and
is intentionally out of scope here; this commit keeps the narrower,
safe fix (a clear coded error) rather than trading a loud crash for
silent data corruption.
Along the way, deduplicated describeDomNode(), which existed as two
near-identical private copies (one in this file's own NG0500 check,
one in platform-browser's dom_renderer.ts insertBefore check) and
moved it into core's hydration/error_handling.ts, shared via the
private ɵdescribeDomNode export.
That function was then removed from every production code path
entirely, per review feedback: computing a human-readable node
description is debug-oriented work that shouldn't ship unconditionally
in production bundles, regardless of how cheap it is — production
should get the bare coded error only, the same as everywhere else in
this file. All three fixes above follow that: ngDevMode && 'message'
in production, no computed description. Confirmed the removal
actually shrinks output, not just assumed it: regenerated all 8
affected bundling symbol goldens, and each one shows exactly one
symbol removed — "describeDomNode" — and nothing else.
Angular's internal LView/TNode bookkeeping can get out of sync with the
real DOM: manual DOM manipulation, a browser extension, or an edge case in
Angular's own view-insertion/reordering code can all leave Angular believing
a node is still attached at a given position when it isn't. The next time
Angular's renderer calls `insertBefore` relative to that stale reference
node, the native DOM API throws an opaque `NotFoundError` with no indication
of which node or component was involved, making these errors effectively
undebuggable in production:
NotFoundError: Failed to execute 'insertBefore' on 'Node': The node
before which the new node is to be inserted is not a child of this node.
at Node.insertBefore (native)
at DefaultDomRenderer2.insertBefore (packages/platform-browser/src/dom/dom_renderer.ts)
at nativeInsertBefore (packages/core/src/render3/dom_node_manipulation.ts)
at nativeAppendOrInsertBefore (packages/core/src/render3/dom_node_manipulation.ts)
... (called while Angular inserts or moves a view during change detection)
Check the reference node's actual parent against the expected parent before
calling the native `insertBefore`, and throw a descriptive `RuntimeError`
(NG05106) instead, following the same pattern already used for hydration
node mismatches.
Adds logic to inject symbols into CSS variables for runtime namespacing.
The runtime now replaces instances of `%NS%` with a namespacing
variable, limiting reach of CSS variables to the current app. An opt-out
syntax of a `--global` prefix allows users to avoid this behavior.
PR Close#68846
The previous fix for GHSA-692r-grfm-v8x7 was incomplete because it rejected script tags only when locating an explicit host element. Dynamic component instantiation can also infer the host element from the component selector.
Move the script-host rejection to the point where ComponentFactory has resolved the host element for either path, so createComponent rejects script hosts consistently.
`animate.leave` was skipped — the element was removed from the DOM
synchronously instead of running its leave animation — whenever a
sibling instance of the same template entered in a different DOM parent
during the same change-detection tick (e.g. an exclusive-expansion
accordion or nav where opening section B collapses section A).
`leavingNodes` is keyed by `TNode`, which is shared by every instance of
a template. When a node was inserted, `cancelLeavingNodes` force-removed
any tracked leaving node whose DOM parent differed from the entering
node's parent (the `leavingParent !== newParent` branch added to
de-duplicate a dynamic component re-rendered into a fresh overlay pane).
For two distinct live sibling instances that merely share a `TNode`,
"different parent" is the normal situation, so the still-animating
sibling was ripped out.
Track the declaration view of each leaving element alongside it, and
only perform the cross-parent removal when the entering element belongs
to the same declaration view as the leaving one — i.e. the same logical
view re-rendered, the case the branch was written for. Two distinct
instances of a shared template have different declaration views, so
their `animate.leave` is now left to run to completion.
This preserves the dynamic-component/overlay de-duplication (#67032) and
the drag-and-drop node-move rescue (#67361), which are unchanged.
Fixes#69291
Introduces `createForeignView`, an internal API for creating foreign view
directly inside `LContainer`s. Foreign views (`TViewType.Foreign`) are bounded
by head and tail comment nodes and can contain dynamic, non-Angular DOM nodes.
Updates Render3 node manipulation to support inserting, detaching, and moving
foreign views along with their internal content.
The `ComponentFactory` has been removed from the public API in #68055.
This commit continues the cleanup and also removes `ModuleWithComponentFactories` from the public API.
This API was deprecated for a longtime, and was remove by #68055 from the public API.
We do have alternatives to this old API, so we can entirely remove it to spare some bytes
This is a minimal implmentation which just focuses on registering parent shadow roots in `SharedStylesHost` correctly.
We don't currently reference count usage of host values, meaning that as soon as we call `removeHost`, all styles are removed from it, even if other components relied on them. Therefore there is no good way to know whether styles are still needed or not, leaving us with the choice of either leaking them longer than necessary or destroying them while another component still needs them. The compromise I'm using here is to delete styles when destroying a component under a shadow root (based on the assumption that only one component will exist per shadow root) and to leave styles when destroying a component in the main document (based on the assumption that dialogs being destroyed should not impact the main application).
Neither assumption is totally safe to make, but we're hoping this is a viable balance for the moment. In the future we should look into lifting these restrictions to better support those use cases while properly reference counting usage of hosts in `SharedStylesHost`.
I also added some small tests to confirm that SSR styles are not duplicated, as an earlier implementation accidentally duplicated them. This should ensure we don't repeat that mistake.
This is to align the shape of the method with `createComponent`
BREAKING CHANGE:The second arguement of appRef.bootstrap does not accept `any` anymore. Make sure the element you pass is not nullable.
fixes#67946
This commit re-introduces support for nested leave animations with a critical adjustment to prevent cross-component blocking. Wait for nested inner `animate.leave` transitions natively only when they exist within the same component's view or its embedded tracking structures (like `@if` and `@for`).
This resolves the issue where route navigations and parental destruction would excessively stall by traversing down into child component architectures to wait for their distinct leaf animations.
BREAKING CHANGE: Leave animations are no longer limited to the element being removed.
Fixes#67633
This reverts commit ea2016a6dc.
This reverts the support for nested animations due to the global scope of how nested animations were gathered.
This caused issues where on route navigations, all child nodes with animations would be queued and run before the navigation would occur.
We'll be revisiting the nested animations with a more tightened scope of when those leave animations will occur.
fixes: #67552
When using ViewContainerRef to rapidly toggle animated elements in
zoneless mode (e.g. CDK Overlay menus), multiple copies of the element
could appear in the DOM. This happened because leave animations were
queued but not yet executed, and the existing `cancelLeavingNodes`
mechanism could not find the leaving element to cancel it — it ran
during template execution before the new element was in the DOM, and
used the declaration container's anchor which doesn't work for
overlay/portal patterns where elements are moved to separate
containers.
Now if there's a leave animation nested within a template, those will animate before the parent element is removed. This makes animating leaving elements a bit easier than before and adds a lot more flexibility to how animations can be structured.
fixes: #66476
When dynamic components are rapidly added and removed with animate.leave and animate.enter, a leave animation might fire before the enter animation could, causing an element to be retained. This fix prevents that from occuring by clearing the enter animations in this case.
fixes: #66794
This commit adds a utility method to debug why the application has not stabilized after
a set period of time (9 seconds, or `hydrationTimeout-1`).
fixes#52912
Currently circular references in user code manifest themselves with an error like `Cannot read properties of undefined (reading 'ɵcmp')`. This is a bit cryptic so these changes add an assertion mentioning circular references.
Relates to #65917.
This ensures that the right document is used and that `CSP_NONCE` can be used in `provideAppInitializer` and `provideEnvironmentInitializer`.
Closes#65624
`new RegExp()` with computed strings can't be analyzed statically. The bundler can't prove the template string evaluation has no side effects; as thus this expression is considered a side-effect.
In some rare cases, it seems the animation queue disappears despite being afterEveryRender. This updates the animation scheduler to be afterNextRender instead and only schedules it when we need to.
fixes: #64423
PR Close#64441
This simplifies code by using async/await instead of rxjs in the config
loading internals. While loadChildren/loadComponent could _technically_
return a synchronous value, the expectation is that this would be used
for dynamic imports, which are necessarily async.
PR Close#64322
Our code ensuring host binding composition for animations was causing the early exit and removal of
elements when multiple transitions were present on the same element. This commit fixes the issue by
ensuring that we properly keep track of all the promise resolvers on the LView and then only
call them once we've properly waited for the longest animation to finish.
fixes: #64209
PR Close#64225
Content Projected nodes are not destroyed and recreated, like every other
situation. Enter and Leave animations were ephemeral and are
expected to run once, and then be cleared. This means that for content projection
cases, the animations would only ever work the first time they were shown / hid.
In order to resolve this, we move to an animation queue that re-runs the animation
functions stored in the LView. In most cases, this animation will run once on creation.
For content projection, the enter and leave animations will fire more than once. Animations
are stored on the LView, but indexed and scheduled by whichever RNode needs to be animated.
So we only run animations for an affected RNode, rather than potentially all in the LView.
This also moves the queue to afterRender, which is safer than right after template
execution in refreshView.
fixes: #63418fixes: #64065fixes: #63901
PR Close#63776
Content Projected nodes are not destroyed and recreated, like every other
situation. Enter and Leave animations were ephemeral and are
expected to run once, and then be cleared. This means that for content projection
cases, the animations would only ever work the first time they were shown / hid.
In order to resolve this, we move to an animation queue that re-runs the animation
functions stored in the LView. In most cases, this animation will run once on creation.
For content projection, the enter and leave animations will fire more than once. Animations
are stored on the LView, but indexed and scheduled by whichever RNode needs to be animated.
So we only run animations for an affected RNode, rather than potentially all in the LView.
This also moves the queue to afterRender, which is safer than right after template
execution in refreshView.
fixes: #63418fixes: #64065fixes: #63901
PR Close#63776
Previously, HOST_TAG_NAME had its __NG_ELEMENT_ID__ set at the top level. This
prevented tree-shaking, since the bundler had to keep the assignment as a
potential side effect even when the token was never used.
This change moves the token creation and __NG_ELEMENT_ID__ assignment into a
@__PURE__ IIFE. If HOST_TAG_NAME is not injected anywhere, the IIFE result is
unused and can be dropped entirely by the optimizer. If it is used, the token
still behaves the same at runtime.
PR Close#63861
This makes the zoneless-by-default change a flag flip that can be
individually enabled in tests, createApplication, and bootstrapModule
for gradual rollout. In addition, the "require on CD provider" check is
also made individually flippable for gradual rollout.
PR Close#63382
This change removes the internally provided `ZoneJS`-based change
detection scheduler. This makes Angular Zoneless by default and allows
tree-shaking of the Zone change detection providers.
BREAKING CHANGE: Angular no longer provides a change detection scheduler
for ZoneJS-based change detection by default. Add
`provideZoneChangeDetection` to the providers of your
`bootstrapApplication` function or your `AppModule` (if using
`bootstrapModule`). This provider addition will be covered by an
automated migration.
PR Close#63382
In production builds, `ngDevMode` is replaced with `false`, so the guard compiles to `return;`. However, bundlers like ESBuild still keep the remaining statements after the return as unreachable code instead of removing them. This leaves behind unnecessary dead code in the output.
Technically, the body is unreachable. But to prove that, the bundler must be 100% certain that:
- `return` cannot be removed by some transform
- there's no later transformation that changes control flow
As thus, it's always conservative.
This also allows dropping `assertDefined`, which was previously
referenced only inside `prependTokenToDependencyPath`. With the
function now fully inlined and dev-only, `assertDefined` is also
eliminated from production builds, further reducing bundle size.
PR Close#63354
To avoid the need for specifying `provideZoneChangeDetection` in any/all
modules used with `downgradedModule`, this change adds the zone-based change detection
providers by default. This also adds the zone providers to
`UpgradeModule` by default as well.
PR Close#63814
The `checkNoChanges` method previously used an early-return guard:
if (!ngDevMode) return;
// dev-only code ...
In production builds, `ngDevMode` is replaced with `false`, so the
guard compiles to `return;`. However, bundlers like ESBuild
still keep the remaining statements after the return as unreachable
code instead of removing them. This leaves behind unnecessary dead
code in the output.
This commit updates the method to instead wrap the full body:
if (ngDevMode) {
// dev-only code ...
}
With this change, the method collapses to an empty function in
production builds:
checkNoChanges() {}
This ensures that the dev-only logic and its dependencies
(e.g. `checkNoChangesInternal`, `UseExhaustiveCheckNoChanges`) can be
fully tree-shaken, reducing bundle size.
PR Close#63387
Alex Rickabaugh