fix: Stop shared dependency objects retaining discarded elements and their DataContext (6.8 port of #25102) - #25839

GitHub Issue: Related to #25099

6.8 port of #25102 to servicing/6.8, in sync with its current head (0efaf28), which was reworked on top of #26123. That PR targets master and is still under review; #25099 stays open until it merges. If the review there changes the fix again, this port will follow.

PR Type:

🐞 Bugfix

What changed? 🚀

Dependency objects that are shared between elements (brushes, transforms, image sources, InputScopes, transitions, ...) kept the last element they were used by, or its DataContext, alive. Through that DataContext they could also keep the whole page alive after navigation. #25099 lists the reference chains.

servicing/6.8 already has two of the fixes: the weak single-parent association of a shareable value, with the guarded DataContext clear on release (#26142, the backport of #26123), and the ToolTip release (#26098, the backport of #25137 and #26096). This PR, rebased on current servicing/6.8, ports what #25102 still adds on top of them. Five commits:

1. fix(transform): Stop shared transforms rooting discarded elements: fix: Stop shared dependency objects retaining discarded elements and their DataContext #25102's 86e5b66, with its follow-up 880cfd2 (popup test portable to WinUI) folded in. Same code as fix: Stop shared dependency objects retaining discarded elements and their DataContext #25102.
2. fix(transform): Register brush, geometry and group handlers weakly: fix: Stop shared dependency objects retaining discarded elements and their DataContext #25102's c331145, plus the two native partials that only 6.x has (Transform.Android.cs and Transform.Apple.cs), which now notify through the weak handlers instead of the removed Changed event. Same code as fix: Stop shared dependency objects retaining discarded elements and their DataContext #25102 otherwise.
3. fix(dependencyobject): Hold a value's inherited DataContext weakly: the 6.x version of fix: Stop shared dependency objects retaining discarded elements and their DataContext #25102's be0c5c1, explained below. Unchanged from the previous version of this PR.
4. fix(dependencyobject): Drop a collected parent's DataContext: fix: Stop shared dependency objects retaining discarded elements and their DataContext #25102's 0efaf28, adapted to how 6.8 pushes a DataContext, explained below.
5. fix(dependencyobject): Read an attached owner's DataContext (b4bacab): 6.8 only. It fixes a throw in commit 4's DataContext comparison, and the same throw in the guarded clear on release that servicing/6.8 already has from fix: Stop shared values on plain DPs retaining their owners (backport #26123) #26142, explained below.

Dropped from the previous version of this PR, because servicing/6.8 has them now or because #25102 dropped them: the ToolTipService commit and its test, the weak _associatedParentRef and the ALC sweep and comment changes that went with it, the Given_CollectibleAlcAssociations rewrite, the rule that a collected parent counts as a second parent (and SingleParentNonFE_Parent_Collected_Then_Next_Parent_Counts_As_Second), and the unconditional DataContext clear in UnassociateParent (and SingleParentNonFE_Parent_Removes_Value_Then_Next_Parent_Starts_Clean). The guarded clear in UpdateChildBindable from #26142 is now the only clear on release.

Commit 3: why 6.8 needs a different DataContext half

On master, #23547 removed DataContext from every object that isn't a FrameworkElement. Such an object keeps the DataContext its element passes down in one plain field, and #25102 only had to make that field a weak reference.

6.8 doesn't have #23547, and can't take it, because it removes public API. On 6.8 every dependency object still has a DataContext property, and the value it inherits from its element is stored like any other property value, with a strong reference. So without commit 3, a shared value still keeps the view model of the last element that used it:

• a shareable value (a brush, for instance) used by a single element that is then discarded: nothing tells the brush that the element is gone, and fix: Stop shared values on plain DPs retaining their owners (backport #26123) #26142's weak association doesn't release the DataContext;
• any other value, such as a shared InputScope or the transitions in a shared TransitionCollection, which keeps the last view model pushed into it, however many elements use it.

It never grows (at most one view model per shared value), but the view model can reference its page.

Commit 3 makes only the inherited (Inheritance precedence) DataContext of objects that aren't UIElements non-owning:

• DependencyObjectStore decides once per object (originalObject is not UIElement) and tells DependencyPropertyDetailsCollection, which applies it to the DataContext property only.
• DependencyPropertyDetails keeps that value in one weak handle per object, of a private type so that no value set by user code can be taken for it. The handle is created with the first non-null value, and again after the value has been cleared; a change only retargets it, so it allocates nothing and takes no lock. Clearing the value frees the handle right away. GetEffectiveValue, GetBaseValue and GetInheritedValue unwrap it.
• Once an object's DataContext has been animated, including by a VisualState setter that targets it, that object keeps its inherited DataContext strongly for the rest of its life, as all objects did before. DataContext is never coerced.

What stays the same:

• UIElements keep their DataContext strongly. The element that passed a DataContext down keeps it alive for as long as it lives, so bindings on its brushes, row definitions, runs, triggers and so on keep working. Those bindings already held their source weakly.
• A DataContext set on the object itself stays strong, for example flyout.DataContext = viewModel in code, or DataContext="{Binding Sub}" on a brush.
• The single-parent rules of fix: Stop shared values on plain DPs retaining their owners (backport #26123) #26142 don't change.

Visible differences, all the same as on master (where these objects have no DataContext property) and in WinUI (which has no DataContext on them):

• Reading DataContext on a brush, transform or other object that isn't a UIElement can return null after a garbage collection, once nothing else holds that view model (the element that provided it no longer has it), even if other elements still use the object. No DataContextChanged event is raised.
• A binding added to such an object after that point resolves against null.

No public API change.

Commit 4: a collected parent's DataContext

Since #26142, a shareable value whose single parent was collected without unassociating counts that parent as no parent, and the next owner becomes its single parent, as in WinUI, where a destroyed parent removes itself from its values (CDependencyObject::ReleaseImpl -> ResetReferencesFromChildren -> RemoveParent). Two things were left behind:

• The expired slot was reused with the DataContext the dead parent had pushed in. On 6.8, an owner pushes its DataContext into a new value only when the assignment changes the property's precedence, so after a same-precedence replacement (an element that already had a local Background, for instance) the value's bindings kept resolving against the old view model whenever it was still alive. The weak storage of commit 3 doesn't help then.
• The dead parent never released its bindable slot, so _bindableHolderCount stayed one too high, and fix: Stop shared values on plain DPs retaining their owners (backport #26123) #26142's guarded clear on release (which waits for the last holder) never fired again for that value: the next owner's DataContext stayed behind once that owner let go.

When AssociateParent reuses an expired slot, it now clears the inherited DataContext unless it already is the new owner's, and leaves a value with its own parent other than the new owner alone (the same guard as the DataContext-change push, ApplyChildrenBindable). ReleaseCollectedParent frees the slot and gives back the dead parent's holder count, there and in the ALC sweep's collected-parent branch.

The difference from #25102: there the DataContext is cleared, and master's on-attach push in UpdateChildBindable then hands over the new owner's DataContext if it isn't null. 6.8 has no on-attach push. Its precedence-change push (TryApplyDataContextOnPrecedenceChange) runs before UpdateChildBindable, so a plain clear would drop the DataContext that push just gave the value; that is why the clear skips a DataContext that already is the new owner's. A reused value now ends where a value used for the first time ends in the same assignment: with the new owner's DataContext after a precedence change, and with none after a same-precedence replacement, where 6.8 pushes nothing into a new value either (unchanged) until the owner's DataContext changes.

Commit 5: an owner whose values live in an attached store

Commit 4's comparison and #26142's guarded clear on release in UpdateChildBindable both read the owner's DataContext with GetValue(DependencyProperty). That overload checks the property's owner when FeatureConfiguration.DependencyProperty.ValidatePropertyOwnerOnReadWrite is on, which is the default in Debug builds and in any build with a debugger attached. A plain object owner such as TextHighlighter, which isn't a dependency object on 6.8, keeps its values in an attached store. That store's DataContext property is owned by AttachedDependencyObject, while the store's type is TextHighlighter, so the check threw "The Dependency Property [DataContext] is owned by [AttachedDependencyObject] and cannot be used on [TextHighlighter]".

TextBlock hits commit 4's read on every draw with a selection: it creates a TextHighlighter for its selection brush, and the previous highlighter has been collected by then. #26142's read throws when a highlighter's brush is replaced. These reads now go through the stores' DataContext details, as SetMentoredChild and RepropagateMentoredChildrenDataContext already do. The values read don't change; only the owner check is skipped.

#25102 and master's #26123 don't need this: on master only a FrameworkElement has a DataContext property, and these reads go through GetInheritedDataContextValue().

Known remaining gap: shared flyouts

A flyout that is shared (app-level or static) and attached through Button.Flyout, FlyoutBase.AttachedFlyout, or the flyout of a SplitButton or DropDownButton, still keeps the view model of the last element it was attached to. With commit 3 the flyout's own DataContext is weak, but 6.8 copies it into UIElements the flyout owns, and those hold it strongly:

• Flyout sets it on its Content as a local value, whenever its DataContext changes, even if the flyout never opens;
• MenuFlyout passes it to its items, which are UIElements;
• FlyoutBase copies it onto its popup as a local value.

ContextFlyout is less exposed: its DataContext is cleared when its element unloads.

Master doesn't have this problem: it removed the popup copy, and #23547 changed how flyouts get their DataContext. Doing the same here would change 6.8's flyout DataContext behavior (content and items would no longer see the owner's DataContext while closed), which is out of scope for a servicing fix. This PR doesn't change it either way.

Performance

Commit 3 keeps one small object (32 bytes on 64-bit, holding a weak GC handle, with a finalizer) per object that receives a DataContext from its element. It is created with the first non-null value, and again after the value has been cleared (for example when the element of a ContextFlyout unloads, or when a shared value loses its only parent). Clearing frees it right away; otherwise its finalizer frees it when the object is collected. A DataContext change only retargets the handle: no allocation and no lock, so no extra garbage collections. Commit 4 only adds work when a value whose parent was collected is reused, and commit 5 makes the reads it touches skip the owner check; commits 1 and 2 don't touch the DataContext path.

Time for 1000 DataContext changes on a panel of 20 controls, with the same probe as in the previous round: each run takes the median of 9 timed rounds after warm-up, and each build had 6 runs in rotating order. This round was measured on Skia desktop only, at this head, in one Release build where a temporary local switch turned commit 3's weak storage off for the "without" runs, so both columns run the same code otherwise. Other builds were running on the machine, so a run's median swung by up to 2x; the lowest timed round over the 6 runs is the steadier number.

The medians are within the noise; the lowest rounds give +5% to +8%. The previous round, on the servicing/6.8 of that time and with little other load, measured +4% to +8% on Skia desktop (medians: Border 2.5 ms to 2.6 ms, Button 25.4 ms to 27.5 ms, TextBox 95.7 ms to 101.1 ms) and +4% to +8% on WebAssembly (Chrome, interpreter; medians: Border 55.5 ms to 59.8 ms, Button 578 ms to 600 ms, TextBox 1815 ms to 1950 ms; +2% to +8% across runs). I didn't measure WebAssembly again: commit 3 hasn't changed since, and the base changes since then (#26142 among them) are on code both builds share. What remains is the weak handle itself: reading or changing such a DataContext is a runtime call. Master pays the same kind of cost for its weak field. Page creation and teardown weren't measured separately; there, each affected object allocates its handle once and releases it once, as master does with its pooled handle.

Tests

From #25102:

• Given_Transform: When_RenderTransform_Shared_By_Style_Then_Discarded_Elements_Collected, When_RenderTransform_Shared_By_Popup_Style_Then_Discarded_Popups_Collected, When_Projection_Shared_By_Style_Then_Discarded_Elements_Collected, When_Transform_Shared_By_Brushes_Then_Discarded_Brushes_Collected, When_Transform_Shared_By_Geometries_Then_Discarded_Elements_Collected, When_Transform_Shared_By_TransformGroups_Then_Discarded_Groups_Collected and the guard When_TransformGroup_Children_Cleared_Then_Removed_Child_Collected. Same file as in fix: Stop shared dependency objects retaining discarded elements and their DataContext #25102.
• Given_BindingMemoryLeak: When_BrushShared_SingleOwner_Removed_Then_Owner_And_ViewModel_Collected, When_TransitionsShared_Removed_Then_ViewModel_Collected and When_InputScopeShared_Removed_Then_ViewModel_Collected. 6.x declares Transitions on FrameworkElement, and not at all on the native mobile targets, so the transitions test uses FrameworkElement.TransitionsProperty and is compiled out there.
• Given_UIElement.DataContext: SingleParentNonFE_Parent_Collected_Then_Next_Parent_Starts_Clean (commit 4) and the guard SharedNonFE_ObjectBinding_Subtree_Severed_Then_Bound_Value_Released (commit 3).

New for 6.x, in Given_UIElement.DataContext:

• SingleParentNonFE_Parent_Collected_Then_Next_Parent_Gets_What_A_New_Value_Gets (commit 4), with a same-precedence replacement and with a precedence change: a bound brush whose first owner was collected while that owner's view model stays alive, assigned to a new owner that has a DataContext, never shows the dead owner's view model and ends with what a brush used for the first time gets in the same assignment (the new owner's DataContext after a precedence change, none after a same-precedence replacement).
• SingleParentNonFE_Parent_Collected_Then_Next_Parent_Has_Attached_Store and SingleParentNonFE_Released_By_Owner_With_Attached_Store (commit 5): with the owner validation on, a TextHighlighter takes a brush whose first owner was collected (the brush must also drop the dead owner's DataContext), and replaces its brush, without throwing.
• NonFE_Inherited_DataContext_Survives_GC_While_Owner_Alive, NonFE_Binding_Added_After_DataContext_Pushed_Then_Resolves, NonFE_DataContext_Bound_To_Sub_Then_Resolves_And_Updates and NonFE_Local_DataContext_Stays_Owned (commit 3, unchanged): they force garbage collections and check that objects that aren't UIElements, and their bindings, still resolve to the right view model, never to the weak handle or to nothing, and that a DataContext set on the object itself stays owned.

Validation

On Skia desktop (Release), at 97a2f17 (commit 4): Given_Transform, Given_BindingMemoryLeak, Given_UIElement (including the DataContext tests), Given_CollectibleAlcAssociations, Given_ResourceDictionary_DataContext, Given_ToolTip, Given_FrameworkElement_And_Leak, Given_SharedTemplate_DataContext, Given_PlainDP_SharedValue and Given_Flyout_PropertyPropagation: 700 test cases, 688 passed, 11 failed, 1 skipped. The 11 failures fail the same way on an untouched servicing/6.8 build on the same machine: 10 Given_UIElement layout-rounding tests at 125% scaling (ActualOffset, TransformToVisual, clip and nesting cases) and Given_FrameworkElement_And_Leak.When_Add_Remove(CommandBarFlyout_Leak).

At b4bacab (commit 5), on Skia desktop (Release), the same classes plus Given_TextBlock: 851 test cases, 838 passed, 13 failed, 4 skipped. 11 failures are the ones above. The other two are Given_TextBlock.When_Inlines_Transitively_Change (a pixel check) and When_IsTextSelectionEnabled_CRLF (a clipboard check, and other processes on the machine share the clipboard). They failed the same way on a 6.8 build without commits 4 and 5 on the same machine.

Red and green, on Skia desktop, with a temporary local switch (not committed) that turns off parts of the product change:

• commit 4 off: SingleParentNonFE_Parent_Collected_Then_Next_Parent_Starts_Clean and the same-precedence row of SingleParentNonFE_Parent_Collected_Then_Next_Parent_Gets_What_A_New_Value_Gets fail: the brush keeps the dead owner's view model;
• commit 4 with a plain clear, as on master: the precedence-change row fails: the brush loses the new owner's DataContext and falls back to its default color;
• commit 3's weak storage off, commit 4 on: the three Given_BindingMemoryLeak DataContext tests fail, the commit 4 tests pass.

These two ran with an earlier form of commit 4 that set the new owner's DataContext instead of keeping it; its holder-count part and commit 3 are unchanged:

• commit 3's weak storage and commit 4 off (the servicing/6.8 DataContext code): the three Given_BindingMemoryLeak DataContext tests and Starts_Clean fail; the other Given_BindingMemoryLeak and Given_UIElement DataContext tests pass;
• commit 4 without the holder-count give-back: Starts_Clean fails at its last step.

Commit 5 off: both of its tests fail with the owner validation exception, the first in AssociateParent and the second in UpdateChildBindable's clear on release.

With the full change, all of them pass. The transform tests are unchanged from the previous round, where they failed without their commits. Commit 3's NonFE_* tests and SharedNonFE_ObjectBinding_Subtree_Severed_Then_Bound_Value_Released are guards: they pass with and without the change.

In Uno.UI.UnitTests (Release, net10.0), the only failures are 13 calendar tests (When_Gregorian_FixedDate* and When_DateTimeOffset_Is_Next_Day_If_Converted_To_Utc) that depend on the machine's time zone, as in the previous round.

Not run this round: Skia WebAssembly runtime tests and the native Uno.UI builds. Commits 1 to 3 are unchanged since the previous round, where they passed on WebAssembly and the native builds succeeded for net10.0-android, net10.0-ios26.0, net10.0-maccatalyst26.0, net10.0-tvos26.0, net9.0-android and net9.0-ios18.0. Commits 4 and 5 only change shared C# in DependencyObjectStore.

PR Checklist ✅

• 🧪 Added Runtime tests, UI tests, or a manual test sample (for bug fixes / features, if applicable)
• 📚 Docs have been added/updated following the documentation template (for bug fixes / features)
• 🖼️ Validated PR Screenshots Compare Test Run results.
• ❗ Contains NO breaking changes
• 👀 Reviewed 2 other open pull requests (optional but appreciated!)