Last Comment Bug 752335 - Lots of Permanent oranges since CPG landed: Test Failure: controller(): Window could not be initialized.
: Lots of Permanent oranges since CPG landed: Test Failure: controller(): Windo...
Status: RESOLVED FIXED
: intermittent-failure
Product: Thunderbird
Classification: Client Software
Component: Testing Infrastructure (show other bugs)
: Trunk
: x86 Windows 7
: -- normal (vote)
: Thunderbird 15.0
Assigned To: Mike Conley (:mconley) - (needinfo me!)
:
Mentors:
Depends on: 751424
Blocks: cpg
  Show dependency treegraph
 
Reported: 2012-05-06 10:06 PDT by Mike Conley (:mconley) - (needinfo me!)
Modified: 2012-11-25 19:31 PST (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Fix _wait_for_generic_load to use Mozmill's new controller.windowMap (1.19 KB, patch)
2012-05-06 13:02 PDT, Mike Conley (:mconley) - (needinfo me!)
no flags Details | Diff | Review
Backport of Mozmill patch (13.16 KB, patch)
2012-05-07 06:27 PDT, Mike Conley (:mconley) - (needinfo me!)
no flags Details | Diff | Review

Description Mike Conley (:mconley) - (needinfo me!) 2012-05-06 10:06:14 PDT
Since compartment-per-global landed (bug 650353), some of our Mozmill tests have started to perma-orange with an error stating that:

Test Failure: controller(): Window could not be initialized.

The Mozmill devs themselves got broken by 650353 (see 751424), and they're rapidly working to fix themselves up.

When their patch lands, we'll have to modify our workaround (bug 666438) in _wait_for_generic_load in test-window-helpers.js, but then we should be back in business.  I just tried an early version of the Mozmill patch with a variation on our workaround with positive results.
Comment 1 Mike Conley (:mconley) - (needinfo me!) 2012-05-06 13:02:14 PDT
Created attachment 621449 [details] [diff] [review]
Fix _wait_for_generic_load to use Mozmill's new controller.windowMap

Henrik says that the Mozmill team is planning on landing their CPG fix in Mozmill 1.5.12 soon, so we're going to have to upgrade.

We'll also need to change our approach to the window workaround we were doing before.  This patch, combined with an early draft of Henrik's work, had good results in test-fixage.
Comment 2 Mike Conley (:mconley) - (needinfo me!) 2012-05-07 06:27:45 PDT
Created attachment 621577 [details] [diff] [review]
Backport of Mozmill patch

Originally merged into the Mozmill 1.5 hotfix branch here:

https://github.com/mozautomation/mozmill/commit/7e8667076c1dc610f6412043cb20e39b330dc30a
Comment 3 Henrik Skupin (:whimboo) 2012-05-07 06:31:41 PDT
Comment on attachment 621449 [details] [diff] [review]
Fix _wait_for_generic_load to use Mozmill's new controller.windowMap

>+++ b/mail/test/mozmill/shared-modules/test-window-helpers.js
>@@ -731,17 +731,20 @@ function _wait_for_generic_load(aDetails
>-  contentWindow.mozmillDocumentLoaded = true;
>+  let windowId = contentWindow.QueryInterface(Ci.nsIInterfaceRequestor)
>+                              .getInterface(Ci.nsIDOMWindowUtils)
>+                              .outerWindowID;
>+  controller.windowMap.update(windowId, "loaded", true);

You should make use of the new utils.getWindowId() method. I have added it to the latest revision of my patch.
Comment 4 Mike Conley (:mconley) - (needinfo me!) 2012-05-07 06:36:05 PDT
Comment on attachment 621449 [details] [diff] [review]
Fix _wait_for_generic_load to use Mozmill's new controller.windowMap

Mark expressed to me how important it was to get these landed and re-open the tree yesterday, so I've brought them in to comm-central

https://hg.mozilla.org/comm-central/rev/dbfa7c06dbfb

and

https://hg.mozilla.org/comm-central/rev/fda8b20e6b21
Comment 5 Mike Conley (:mconley) - (needinfo me!) 2012-05-07 06:36:25 PDT
(In reply to Henrik Skupin (:whimboo) from comment #3)
> Comment on attachment 621449 [details] [diff] [review]
> Fix _wait_for_generic_load to use Mozmill's new controller.windowMap
> 
> >+++ b/mail/test/mozmill/shared-modules/test-window-helpers.js
> >@@ -731,17 +731,20 @@ function _wait_for_generic_load(aDetails
> >-  contentWindow.mozmillDocumentLoaded = true;
> >+  let windowId = contentWindow.QueryInterface(Ci.nsIInterfaceRequestor)
> >+                              .getInterface(Ci.nsIDOMWindowUtils)
> >+                              .outerWindowID;
> >+  controller.windowMap.update(windowId, "loaded", true);
> 
> You should make use of the new utils.getWindowId() method. I have added it
> to the latest revision of my patch.

Thanks Henrik - I'll write a follow-up patch to fix that once we get our tree back open.
Comment 6 Mike Conley (:mconley) - (needinfo me!) 2012-05-07 10:40:04 PDT
Looks like it worked. No more Window could not be initialized errors on comm-central.

\o/

Note You need to log in before you can comment on or make changes to this bug.