Test window state changes through the buttons present on the window's chrome
What is the problem or limitation you are having?
Related PR: #2364
Context:
There are 2 ways that a window's state can be changed.
- Through the native window state APIs.
- Through the buttons present on the window's chrome.
From preliminary testing, it seems that changing the window state through the native APIs has a slightly different behavior than changing the window state through the buttons on the window's chrome(At least on winforms from current testing).
Currently, the testbed is only testing window state changes which are triggered through the APIs. But it is not testing window state changes which could be triggered by the user directly using the buttons on the window's chrome, or restoring them from the taskbar/dock.
This gap in testing can become problematic, as users are more likely to change window states using the buttons on the window's chrome. Such a gap could conceal potential behavioral bugs that differ from the behavior observed when using the APIs.
Additional context
To implement such tests, new probe methods need to be developed. I will add more context on how these probe methods could be added later on.
It's entirely plausible that there are differences in window behavior depending on how window resizes are activated; however, I'm not sure we have any practical mechanism to activate windows via their chrome. I'm happy to be proven wrong on that front - if it is possible, and it reveals testing differences, then sure - we should add tests for those behaviours.