Winforms: Setting ComboBox.SelectedItem changes order of controls in TableLayoutPanel

[swythan]

• .NET Core Version:
  3.1.1

• Have you experienced this same bug with .NET Framework?:
  Yes
  It looks like a regression from 4.7.2 to 4.8. I'm filing a bug there too.

Problem description:
Short version:
In a specific situation, setting SelectedIndex/SelectedItem on a ComboBox can cause the controls in a TableLayoutPanel to change order (in the Controls collection and also visually).

Long version:
We have a form that involves dynamically adding rows to a TableLayoutPanel. Each row contains a mix of ComboBox and TextBox controls. After adding each row of controls, we set the SelectedItem/Index on each ComboBox. One of the ComboBoxes has an SelectedIndexChanged event handler that modifies the SelectedIndex of one of the other ComboBoxes in the same row.

On .Net 4.7.2 (and earlier) this works fine. On .Net 4.8 & .Net Core 3.1 two of the controls in the first row of the TableLayoutPanel are swapped. The swap is apparent both in the order of the controls in the Controls property of the TableLayoutPanel, and also visually in the rendering of the form (i.e. they are inthe wrong columns). Note that neither of the swapped columns is involved directly in the above mentioned event handler.

Expected behavior:
Changing the SelectedIndex should not cause the controls to change order.

Minimal repro:
https://github.com/swythan/BugRepro.WinFormsComboBox

[swythan]

The problem is caused by the code around here:
https://github.com/dotnet/winforms/blob/c992a627324412365bf8f59ec606c35df404288b/src/System.Windows.Forms/src/System/Windows/Forms/ComboBox.cs#L2784

It was part of PR #400, which ported some accessibility fixes from .Net Framework 4.8.

AFAICT it's the creation of the accessibility shim for the ComboBox that triggers the issue. That ends up creating the window handle for the control (note that it's not been displayed, yet). Somehow the handle creation ends up calling back into WinForms (sorry I can't remember where now, maybe Control.UpdateChildControlIndex) and triggering some code that re-orders the controls.

[swythan]

Reported for .Net Framework 4.8 here:
https://developercommunity.visualstudio.com/content/problem/903310/setting-comboboxselecteditem-changes-order-of-cont.html

Note that .Net Framework you can avoid this bug by using quirks to disable these new accessibility features. You obviously can't do that in netcore, though.

[RussKie]

@M-Lipin please investigate

[M-Lipin]

The issue does not reproduce in .NET Core 5.0.

[M-Lipin]

@RussKie do we need more actions on this?

[swythan]

Please re-open.

I can live with you not fixing it in .Net 3.x, but the bug I logged in .Net Framework was closed saying that it would be tracked here.

I'd imagine that whatever the fix is/was should be back-ported, as it was a regression in the last NetFx release.

[RussKie]

as it was a regression in the last NetFx release.

This repo is for .NET Core/.NET version of Windows Forms.
We port fixed to .NET Framework only under specific conditions (like a security issue), and this one doesn't meet the bar.

The issue does not reproduce in .NET Core 5.0.

If this repro's in 3.1 we may need to service it.
Please prepare a fix.

/cc: @merriemcgaw

[swythan]

We port fixed to .NET Framework only under specific conditions (like a security issue), and this one doesn't meet the bar.

From https://devblogs.microsoft.com/dotnet/net-core-is-the-future-of-net/ [emphasis added]

.NET Framework 4.8 will be the last major version of .NET Framework. If you have existing .NET Framework applications that you are maintaining, there is no need to move these applications to .NET Core. We will continue to both service and support .NET Framework, which includes bug–, reliability– and security fixes.

@John-Qiao, @RussKie is the policy for getting a fix into a NetFx service release public? I'm surprised that regressions don't make the cut automatically, as there is no SxS install of NetFx (hence the push to .Net Core).

[weltkante]

This repo is for .NET Core/.NET version of Windows Forms.

Unfortunately bug reports against Desktop are often redirected here anyways.

[swythan]

This repo is for .NET Core/.NET version of Windows Forms.

Unfortunately bug reports against Desktop are often redirected here anyways.

Yes.

@John-Qiao If this issue isn't going to drive a back-port to NetFx, can you please re-open the issue on Developer Community?

[merriemcgaw]

Yes, please reopen the Developer Community issue, and @M-Lipin or @vladimir-krestov will get it ported to .NET Framework. I can't promise a particular release date as we have to get approval from both .NET Framework and Windows Servicing shiprooms. But we can get this in the queue for a future ship date. This issue should track the .NET Core impacts for the issue.

@John-Qiao can you please create an issue in AzDO to track the code changes and shiproom submisssion? We'll link it to the feedback issue and get the ball rolling.

[John-Qiao]

@swythan we have re-open this issue on Developer Community, and created a bug to tracking it. Thanks.

[swythan]

Thanks, everyone.

[merriemcgaw]

I want to service this in 3.1. It's a very yucky regression that would impact porting of applications.

[M-Lipin]

Added a servicing PR with the fix above. This is already fixed in .NET Core 5.0.