Radiobutton with GroupName sets value false second time window is opened

OpterJohan commented 1 month ago

Description

A wpf Window that has a set of RadioButton controls with GroupName set and IsChecked bound to an underlying property will set that property to false when a second instance of that window is opened after the first instance is closed.

If the GroupName attribute of the RadioButtons is not set, the property is not changed when opening a second window.

This is very similar to issue #2995 that was reported as fixed in October 2023 and possibly related to (same as?) issues #3751 and #7462 that were closed due to lack of repro.

Reproduction Steps

A minimal repro project is available here: https://github.com/OpterJohan/RadiobuttonIssueRepro Steps to reproduce:

run the wpf app
press the "Open details window" button (A window named Details with 2 radio buttons opens. The radio button "Option 1" is set)
close the "Details" window
press the "Open details window" button again (The Details-window opens again, but this time both the radio buttons "Option 1" and "Option 2" are not set)

If DetailsWindow.xaml is changed to that the radio buttons do not have GroupName, "Option 1" is set the second time the window is opened as well.

Expected behavior

Bound property should be unaffected by old closed windows. The behaviour should be the same regardless if a GroupName is given.

Actual behavior

Bound property is set false.

Regression?

Possible regression of #2995.

Known Workarounds

Run GC.Collect before opening the window again seems to work in the minial repro project. Unclear if it would always work.

Impact

Makes is more difficult to create a UI with multiple sets of radio buttons.

Configuration

.net 8.0.2 Windows 11 10.0.22631.0, x64.

Other information

No response

miloush commented 1 month ago

possibly duplicate of #2995?

OpterJohan commented 1 month ago

That's what I thought too at first, but #2995 was closed as completed on Oct 11, 2023.

miloush commented 1 month ago

Hm, but I cannot repro on 9.0.100-preview.1.24101.2. Maybe that fix did not make it to 8.0.2 version?

OpterJohan commented 1 month ago

With the latest preview of dotnet 9 it works for me, too. Strange if the fix for #2995 would not be in 8.0.2, it was merged on October 9, 2023 and verified as fixed in .net 8 RC2.

ThomasGoulet73 commented 1 month ago

The code looks like it was never backported to .Net 8.0, it might be a mistake that someone confirmed it was fixed in .Net 8.0 RC2.

The code in the PR does not exist in the .Net 8.0 RC2 tag nor in the .Net 8.0 release branch.

ThomasGoulet73 commented 1 month ago

Also WPF, like most of the .Net projects (dotnet/runtime, dotnet/winforms, etc), branch off of main before .Net 8.0 GA. Which means that PRs merged into main after this date will not be included in .Net 8.0 by befault, it requires a manual backport. IIRC the date of the cut off is around the first RC version, so the PR dotnet/wpf#8202 was not included in .Net 8.0 because it was not manually backported.

OpterJohan commented 1 month ago

Ok, that explains it then, thanks to both of you for looking into it. Do you know what the policy is on backporting non-critical bug fixes like this one? Any chance it will make it to a future .net8 release or do we simply wait for .net9?

harshit7962 commented 1 month ago

@OpterJohan as discussed above this fix was made in .NET 9. Regarding backporting of the fix, we would require a proper business impact and justification. The details of impact justification will make it certain for the fix to be backported. Requesting help with any data in support of the impact of this bug.

OpterJohan commented 1 month ago

Thanks again. Here is some input on impact and justification for backporting the fix.

For us, the impact is that we will need to look over all UI that contains the RadioButton control to make sure the bug does not harm user data. We will also need to keep it in mind in future work. This bug probably affects thousands of wpf projects out there but since it is not obvious, chances are it manifests as randomly unstable behaviour - "sometimes my data has changed and I'm sure I didn't do it".

If the fix is not backported, the bug will continue to affect new and old projects alike for years to come since .NET 8 is a "long term support" version. As the fix is quite simple, backporting it poses minimal risk.

OpterJohan commented 2 weeks ago

Any updates on whether the fix will be backported or not?

dotnet / wpf