• .NET Core Version: 3.0
• Have you experienced this same bug with .NET Framework?: No

In PR #2103 following comment was noticed:

no way to add Font.Name and associate it with FontNameEditor

Thats unfortunate, but the good news is that its the only [Editor] attribute in System.Drawing thats placed on a property (verified by doing reflection on the Desktop Framework assembly, looping over all types and properties)

Considering that the only purpose of this "editor" is to draw the font name in the same style as the font it's not even an editor. I want to open a discussion on how to proceed with this:

a1) remove FontNameEditor entirely since it provides no actual value to the user editing

a2) keep FontNameEditor (since it is public API and someone may happen to use it) but do not link it to the Font.Name property. This would basically keep the behavior as it is now (which does not match Desktop Framework) and make it "official" for .NET Core. Third party users happening to use the editor would still compile.

b1) remove FontNameEditor from WinForms and place it in the VS designer instead. The VS Designer Package already has its own more complex extensions to TypeDescriptor and might have less trouble adding this one. This means for user-written designers it won't be available.

b2) similar to a2, keep FontNameEditor in WinForms since its public API, but like described in b1 only link it up in the VS designer. Third party users outside the VS designer could use it but would need to register it manually.

c) extend TypeDescriptor in CoreFX to allow registering default editors on properties, keep the FontNameEditor in WinForms and register it using the new functionality

Given this doesn't impact any functionality (its just for visuals) it probably doesn't need to go into 3.1 and can be resolved later.