fix(visualstates): fix rolling back properties when the next state doesn't modify a property, but modifies one of its subproperties

[ramezgerges]

GitHub Issue (If applicable): closes #

PR Type

What kind of change does this PR introduce?

What is the current behavior?

What is the new behavior?

PR Checklist

Please check if your PR fulfills the following requirements:

• [ ] Docs have been added/updated which fit documentation template (for bug fixes / features)
• [ ] Unit Tests and/or UI Tests for the changes have been added (for bug fixes / features) (if applicable)
• [ ] Validated PR Screenshots Compare Test Run results.
• [ ] Contains NO breaking changes
• [ ] Associated with an issue (GitHub or internal) and uses the automatic close keywords.
• [ ] Commits must be following the Conventional Commits specification.

Other information

Internal Issue (If applicable):

[ramezgerges]

cc. @kazo0, this should fix the Toolkit visual states regression.

[unodevops]

🤖 Your Docs stage site is ready! Visit it here: https://unodocsprstaging.z13.web.core.windows.net/pr-16714/index.html

[unodevops]

🤖 Your WebAssembly Sample App stage site is ready! Visit it here: https://unowasmprstaging.z20.web.core.windows.net/pr-16714/index.html

[unodevops]

🤖 Your Docs stage site is ready! Visit it here: https://unodocsprstaging.z13.web.core.windows.net/pr-16714/index.html

[unodevops]

🤖 Your WebAssembly Sample App stage site is ready! Visit it here: https://unowasmprstaging.z20.web.core.windows.net/pr-16714/index.html

[unodevops]

🤖 Your Docs stage site is ready! Visit it here: https://unodocsprstaging.z13.web.core.windows.net/pr-16714/index.html

[unodevops]

🤖 Your WebAssembly Sample App stage site is ready! Visit it here: https://unowasmprstaging.z20.web.core.windows.net/pr-16714/index.html

[kazo0]

fyi @ramezgerges, this original fix seemed to have fixed https://github.com/unoplatform/uno/issues/14262

So rolling it back might unfix it, maybe?

@eriklimakc maybe check from this branch if the issue happens again

[ramezgerges]

@kazo0 It shouldn't. The title is a bit misleading :). This PR doesn't "roll back" the previous fix, but it fixes a certain scenario where some properties set by animations should not be rolled back (they get rolled back after the other PR when they shouldn't). So it does indeed move some cases to the old behaviour, but it's very unlikely that that was what fixed #14262.

[eriklimakc]

It works fine with the changes from this PR :)