MenuStrip highlight "sticks" after menu item is activated, also affects keyboard focus

[rickbrew]

.NET version

.NET 9.0.0-preview.7.24405.7 x64

Did it work in .NET Framework?

Yes

Did it work in any of the earlier releases of .NET Core or .NET 5+?

This worked fine in .NET Framework 2.0 all the way up through .NET 8. This is a new regression in .NET 9.

Issue description

When using MenuStrip, the highlight for a top-level menu item is "sticking" after the menu is closed, either by canceling out of the menu (e.g. Esc or click) or when activating a menu item.

This may also be doing some weird things with focus -- I found this after migrating Paint.NET to use .NET 9, and I'm also seeing that keystrokes which should go to the main canvas area are being ignored, as if the MenuStrip still has focus. I can provide access to the PDN source GitHub repo for a MSFT employee if they'd like an extended repro (minimal repro is attached below) and/or to do extended testing to make sure it's fix. This is pre-approved/arranged via @richlander

I also noticed that using a keyboard shortcut for a menu item will cause the containing top-level menu to be highlighted. For example, in my current Paint.NET v5.1 + .NET 9 build, if I press Ctrl+Z for Edit->Undo, the Edit menu will be highlighted and also steal focus.

Worth noting is that this is a ship blocker for me. I can't release my next big update with this bug (I mean, I'd have to revert to .NET 8). I am planning to release my v5.1 update sometime in November or December, after .NET 9 "RTM" is released.

Steps to reproduce

I have a minimal repro to illustrate this.

WinFormsApp1.zip

1. Start up the app and you'll see the main window
   

2. Open the File menu by clicking on it, or pressing Alt+F
   

3. Activate the "New" menu item by clicking on it, or pressing N, or pressing Enter (since it's already selected)
   

4. Notice that the File menu is still highlighted while the modal dialog is open. It should not be highlighted at this point.

5. Click OK to dismiss the dialog

6. Notice that the File menu is still highlighted. It should not be highlighted at this point.
   

You can retarget the app to use .NET 8 by editing the .csproj, and it will not behave like this. The File menu is not rendered with its highlight at steps 4 and 6.

[KlausLoeffelmann]

Investigating right now. This might have to do with the Dark Mode Experimental Feature.

[KlausLoeffelmann]

Nope, it has not anything to do with the new Dark Mode feature.
I just tested it with test binaries for the Async Feature. Those are from a few days before dark mode went in, and it shows already that behavior. So, it must have regressed earlier. I keep investigating.

[KlausLoeffelmann]

Discussed with @lonitra - #11449 seems to be causing this.
I tested reverting this, and it seems after that working fine again:

[KlausLoeffelmann]

@rickbrew:

Hey Rick,

I am trying to get this in into RC1 - and keep you posted. (It needs Tactics team approval.)
Reopening this, so we can use this as a progress tracker.

Please note, that we have Dark Mode as an Experimental Feature in .NET 9, and if you consider using/trying this particularly for getting dark themed scrollbars, we're of course super interested in feedback!

That said, there is a series of things we need to address to make dark mode perfect (and that's planned and expected). Also, there are some controls (like the Month Calendar), which might never get proper theming for this. That's why the feature is attributed Experimental, and primarily, this is to collect feedback, so we can have a perfect-as-possible solution for .NET 10.

Please also ping me directly with any issues you see.

Thanks,

Klaus

[rickbrew]

@KlausLoeffelmann I appreciate it! Is there anything I can do to assist?

What's the cutoff for RC1? I should probably do a custom .NET 9 build w/ the fix so I can verify within Paint.NET, and also test to see if there are any other new bugs to file issues for. My time is limited this week though, so knowing the cutoff will help me prioritize things.

I'm already using my own custom dark theme "hacks" for things like scrollbars, but switching to the built-in implementation would be great. And there's a few controls here and there that I haven't had the time to get dark theme-ified.

[KlausLoeffelmann]

So, for RC1 this must happen comparatively quickly-quickly-quickly.
And the bar is really high.
If it's something serious (which I don't think at this point there is), we could still address for RC2.

But we need to keep in mind: We're not able to do any feature work or styling improvements.
That would be in the .NET 10 timeframe.

But let's sync up offline - it would make sense to talk about issues and synergies, since 90% of .NET Paint is already pretty darkmodable.
Ping me at klaus dot loeffelmann and then the MS @ part, if you want to continue offline!

[Olina-Zhang]

Verified this issue in the latest .NET 9 RC1 build: 9.0.100-rc.1.24421.9 from https://aka.ms/dotnet/9.0.1xx-rc1/daily/dotnet-sdk-win-x64.exe, it was fixed:

[Philip-Wang01]

Verified the issue with .NET 9.0.100-rc.1.24422.10 test pass build that the issue has been fixed, which have the same results as above.