none
Where to submit bugs found in UI Automation? RRS feed

  • Question

  • Hi,

    Is there a place one can submit bugs found in UI Automation?

    For the past few weeks I have hit a few definite, reproducible bugs in the UI Automation native API. Posting on this forum does not seem to help much, my bug reports remain ignored here. What is the best way to submit problem descriptions to Microsoft?

    Thanks.

    Thursday, October 21, 2010 3:12 PM

Answers

  • Hi, Najaryan,

    Let me try to clarify: It is extremely useful to us when you report issues in UI Automation.  This particular class of issues is known right now, so reporting similar issues of this class doesn't add more value.

    My situation as both a developer on Windows and a forum participant is challenging: I can agree with you that it would be helpful to have timeouts on calls, and even talk hypothetically about the form that such timeouts might take, but I can't talk about plans for future releases of Windows, or say definitively whether we would build such a feature. 

    So, I think this limitation is not inherent to the nature of UIA, but it's certainly the nature of UIA in Windows 7. 

    It's not quite accurate to say that every other Windows API has configurable per-call timeouts.  MSAA, the predecessor to UIA going back to 1995, does not.  WinSock, the Unix-compatible networking API, also does not.  (e.g.: http://msdn.microsoft.com/en-us/library/bb530747(v=VS.85).aspx)  Or, more correctly, WinSock did not for a long time, and they were added later as options for setsockopt().  So, there are certainly other APIs that added timeout-configuration features later.

    Back to the original problem: Yes, a helper process could do the job as you described.  You could try a similar technique at the thread level, but I tend to think you'd get leaked resources and process instability. 

    Thanks,
    Michael


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Tuesday, November 2, 2010 3:21 PM

All replies

  • Hi, najaryan,

    I think forums are fine places to report issues you are noticing, but if you are looking for time-sensitive responses, you may wish to try the MSDN Assisted Support options:
    http://msdn.microsoft.com/en-us/aa570318.aspx

    I do my best to keep up with the forum, but I keep this up in my free time, which can be limited.

    Thanks,
    Michael 


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, October 29, 2010 4:23 PM
  • Michael, thanks for responding.

     

    I reported two (probably interrelated) issues on this forum and received no response:

    1. http://social.msdn.microsoft.com/Forums/en/windowsaccessibilityandautomation/thread/1f6e04de-a3c7-4f4d-a629-10f42c92cbbc (This one includes full source code to reproduce the problem)

    2. http://social.msdn.microsoft.com/Forums/en-US/windowsaccessibilityandautomation/thread/495f5302-d8f0-468f-ae2e-9c96aa03ff36

    I am happy to provide any additional details you need including simple MSVC projects with full source code that will make it easy for you to reproduce and see the problems.

    There are other issues which I was hesitant to post here since I received no feedback on those two and I would hate to think I am spending hours of my time to compose reproduction cases but nobody cares to have a look.

    Friday, October 29, 2010 5:00 PM
  • Thanks, Najaryan,

    I responded briefly to the first one.  Thanks for the full source code -- we've run into that one internally, so we do know about it.  You are correct that the second issue is essentially the same as the first one, which is why I didn't jump on replying to that one.

    Thanks,
    Michael


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Monday, November 1, 2010 7:38 PM
  • Michael, thanks for replying.

    Do I understand it correct that there is not much point in reporting other similar issues which result in infinite blocking of UI Automation API calls under various situations?

    If this is the nature of UI Automation API would it not be usefull to have optional timeouts for the calls? AFAIK every other Windows API which is capable of blocking the calls has some means to configure the timeouts. No other Windows API call will block infinitely unless the programmer explicitely specifies such an option (e.g. INFINITE flag to WaitForSingleObject call).

    Returning to the original problem. It looks like one possible reliable way to use UI Automation API is by using a helper process to make API calls and monitor the process via a watchdog. If it becomes blocked the process can be terminated and restarted without affecting the primary process. Do you know of any other technique that can guarantee that my application will not suddently become blocked when making a UI Automation call?

    Thanks again for getting back quickly.

    Tuesday, November 2, 2010 12:55 PM
  • Hi, Najaryan,

    Let me try to clarify: It is extremely useful to us when you report issues in UI Automation.  This particular class of issues is known right now, so reporting similar issues of this class doesn't add more value.

    My situation as both a developer on Windows and a forum participant is challenging: I can agree with you that it would be helpful to have timeouts on calls, and even talk hypothetically about the form that such timeouts might take, but I can't talk about plans for future releases of Windows, or say definitively whether we would build such a feature. 

    So, I think this limitation is not inherent to the nature of UIA, but it's certainly the nature of UIA in Windows 7. 

    It's not quite accurate to say that every other Windows API has configurable per-call timeouts.  MSAA, the predecessor to UIA going back to 1995, does not.  WinSock, the Unix-compatible networking API, also does not.  (e.g.: http://msdn.microsoft.com/en-us/library/bb530747(v=VS.85).aspx)  Or, more correctly, WinSock did not for a long time, and they were added later as options for setsockopt().  So, there are certainly other APIs that added timeout-configuration features later.

    Back to the original problem: Yes, a helper process could do the job as you described.  You could try a similar technique at the thread level, but I tend to think you'd get leaked resources and process instability. 

    Thanks,
    Michael


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Tuesday, November 2, 2010 3:21 PM
  • Michael,

    I understand that you can't talk about future releases of Windows. I simply expressed a desire as a developer and hope that it may have a small impact on future UI Automation development.

    I did not know setsockopt() was not in the original WinSock :-)

    I do not think a helper thread will do it since there is no way to gracefully terminate a blocked thread without potential harm caused to the entire process (and it is not just resource leak, it can me much worse if for example the thread is terminated in the middle of heap allocation routine resulting in process heap corruption or non-release of heap critical section).

    Once again, thank you for taking time to reply. I will make sure to report bugs if I find any that are not related to this particular issue.

    Tuesday, November 2, 2010 4:07 PM