Implement unit tests for the Plugin Hang UI.

How long do these tests take to run end-to-end? I don't know if the automation people are ok with tests that "sleep": https://developer.mozilla.org/en-US/docs/Mozmill_Tests/Mozmill_Style_Guide#Sleep%28%29 If the test machine is very busy, is it possible for some of these tests to fail if it takes longer than expected for the UI to come up? That would lead to intermittent orange :(

This version uses some Windows accessibility APIs to detect dialog start and end. This allows the tests to be event driven, instead of relying on a bunch of events to coincide and then polling for them. The entire suite took roughly one minute to run on my laptop. I'll push to try to see how we do on there.

This revision of the regression tests runs green on everything, including Windows XP. \o/ I also made a minor change to the Plugin Hang UI child process. I discovered that the UI having a NULL owner window was causing Windows to promote the Mochitest command prompt window to the foreground ahead of Firefox (probably because it noticed that the Firefox process was hanging during the tests). Not only is this unsightly to the user, but it breaks other Mochitests by doing so! Now we set foreground explicitly. Note that this will not steal foreground from other programs; the window manager only allows the Plugin Hang UI to set foreground if the Plugin Hang UI itself is the current foreground process.

Comment on attachment 735845 [details] [diff] [review] Plugin Hang UI mochitests v3 hrm. As much as I applaud the ingenuity of this patch using ctypes to send messages, it seems like we're reinventing a UI automation framework. Did you talk to somebody in testing to see if there's a framework that already exists (ask Ted, I guess)? I'm going to mark r+ on this because it looks reasonable, but I'd prefer a real UI framework if we have one.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #5) > Comment on attachment 735845 [details] [diff] [review] > Plugin Hang UI mochitests v3 > > hrm. As much as I applaud the ingenuity of this patch using ctypes to send > messages, it seems like we're reinventing a UI automation framework. Did you > talk to somebody in testing to see if there's a framework that already > exists (ask Ted, I guess)? I'm going to mark r+ on this because it looks > reasonable, but I'd prefer a real UI framework if we have one. Ted, do we have a UI automation framework for testing something like this?

I'm not aware of any existing Win32 UI automation that we actually use.

Still getting random WinXP oranges on inbound. :-( Backing out for the moment while I work on a fix. http://hg.mozilla.org/integration/mozilla-inbound/rev/bbac34f292cf

I've retested this stuff on Try and it is running green consistently. The landing of bug 852164 fixed the intermittent problems with this test. Rebased, carrying forward r+. https://tbpl.mozilla.org/?tree=Try&rev=2898c16da841 https://hg.mozilla.org/integration/mozilla-inbound/rev/443dcdf8eed2