Animating an inherited property doesn't work (sometimes)

[SamBent]

• .NET Core Version: any
• Windows version: any
• Does the bug reproduce also in WPF for .NET Framework 4.8?: Yes. Repros in 4.0+ (regression from 3.5)
• Is this bug related specifically to tooling in Visual Studio (e.g. XAML Designer, Code editing, etc...)? no
• Security issues and bugs should be reported privately, learn more via our responsible disclosure guidelines.

Problem description: Animating an inherited property doesn't work in some cases. It works if the host element has had an inherited property set directly, even one different from the one being animated. It (sometimes) works if a second inherited property is already being animated. Sometimes it doesn't work until you do some other action, after which it works. In other cases, it may not work at all. There is no simple pattern.

The attached repro declares a style for TextBlock that contains triggers to animate its Foreground and LineHeight properties (both are inheritable). It displays four instances of TextBlock using the style, but with different initial settings for the properties. Each comes with buttons to activate the two triggers. All four should work the same way, but the repro illustrates that they depend on outside factors or previous behavior. (The repro demonstrates four interesting cases, but it doesn't illustrate all the bizarre ways this can fail.)

Expected behavior: The "Trigger FG" button animates the TextBlock's Foreground, causing its text to turn red.

Actual behavior: The "No Inheritance" and "Inherit Foreground" instances don't work initially, but start working after you click the "Trigger LH" button. The "Inherit LineHeight" instance doesn't work at all. The "Set LineHeight" instance works correctly.

Minimal repro:
Repro.zip

Remarks: This bug is responsible for the failure of some test cases in .NET 4.0+, including one that recently arose while testing an unrelated servicing fix. The test cases aren't testing this scenario directly, but they make runtime choices that occasionally stumble across the bug. For a while it appeared that the failure happened only on Win8.1 + .NET 4.7.2 (and only when no debugger was attached), but it turns out that the OS, .NET version, debugger, etc. all influence the runtime choices, and only rarely produce a failing case.