Do not create accessible objects until owner control is created

[RussKie]

Is your feature request related to a problem? Please describe.

Currently an accessibility object can be created before its owning control is materialised (i.e. have a valid Handle):

// .NET 5.0 sample

var button = new Button();                     // handle is not yet created
button.AccessibilityObject.DoDefaultAction();  // accessible object is created

form.Controls.Add(button);
form.Show();                                   // button.Handle is created

Such design places a lot of responsibility on SDK to constantly check and guard against accessing an owner control and its handle before their are fully created and live.

A lot of work has been done in response to https://github.com/dotnet/winforms/issues/3062, which added a lot of code (e.g. https://github.com/dotnet/winforms/pull/3432), and has a perf impact (as negligible as it may be). However with the steady stream of accessibility-related work there is a significant overhead in implementing guards and rails against accidental handle access.

Describe the solution you'd like and alternatives you've considered

It makes no sense to access an accessibility object before its owner is materialised, i.e. a non existent control can't be navigated to or inspected in any accessibility tools (e.g. Inspect or AI4Win).

We should consider the following:

1. not creating an instance of accessibility object until its owner is fully materialised and has a valid Handle,
2. removing all unnecessary null checks and handle checks in ControlAccessibleObject and its descendants

[weltkante]

not creating an instance of accessibility object until its owner is fully materialised and has a valid Handle,

Should the AccessibilityObject return null or throw in this case? (I don't have a particular opinion just wanted to bring up this option.)

[RussKie]

This is a good question, thank you! My initial feeling was to return null, but since it would be a breaking change throwing would be equally appropriate. I expect we will discuss this internally, and welcome external thoughts and opinions as well.

[vladimir-krestov]

I have made a primary investigation, if we can set AccessibleObject as null.

Why do we need it:

• We will avoid many "IsHandleCreated" checks, this will clean up the code and make it faster
• Code implementations will have less code paths, so it will reduce unit tests count
• We will avoid feature bugs like #2797

Issues:

• After #3432 we reduced chanse of appearence bugs like #2797 because we have many checks now. These bugs happen very seldom, it's simpler to add one more "IsHandleCreated" check instead of creating one universal solution. We can't take into account all use cases
• It's time-consuming fix. AccessibleObject property has about 620 usings and about the same count of related cached properties (eg. DataGridView.EditingControlAccessibleObject property)
• We will have to rework thousands of unit tests. It will take much time
• We will bring many bugs due to logical mistakes or typos in thousands lines of the fix. We are not robots
• We can catch NullReferenceException somewhere via a long call-stack
• We can fix more the rest issues instead of fixing this hard one
• We may affect Designer, we will have to support its implementations too
• We are breaking the public API (AccessibleObject property). It makes customers to fix their applications, rework and check all their implementations, spending lots of time and money. This point makes porting to 6.0 more difficullt. The possible customer code examle: control.AccessibleObject.Name = "Some text"; Castomers may have something like that somewhere in their code before creating controls and a form, our changes make them to find and resolve them, and if customers don't catch all of them, their users may have errors
• We will violate the open–closed principle states "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification". In our case, we can't use something like "InternalAccessibleObject" because root objects of our controls are taken from the AccessibleObject property

Conclusion: I don't like this change. I see only negative effects. There are more disadvantages then advantages. My opinion - don't touch that is working. We will bring many problems to customers for the sake of the code clean up and the performance micro improvement.

My proposal: Keep it as is. Add more "IsHandleCreated" checks, that are missed for new implementations made after #3432

//cc: @merriemcgaw

[RussKie]

Thank you.