The frame navigation tests added in bug 408052 assume they're being run on Firefox. When using nsIWindowWatcher to find open windows, the tests assume they're getting a Chrome window and reach inside to find the gBrowser. However, the gBrowser won't be there on embedding builds -- apparently nsIWindowWatcher will return a content window instead. We should detect whether the window watcher gave us a ChromeWindow or a content window to decide whether to find its child windows. (Ideally, it would be nice if nsIWindowWatcher had some way to enumerate content windows directly, but perhaps that's too much to ask.)

Yeah, windowwatcher basically just returns what people tell it about, and XUL-based apps tell it about the toplevel XUL windows. And it's frozen, more the fun.

Based on comments from bz, we think this patch will let the tests will work in embedded builds, but we aren't sure how to run the tests in that mode.

Hmm... For ChromeWindow, I'd prefer we stick with the gBrowser thing or something. frames could include all sorts of random UI stuff, in the future... And there's no obvious way yet to run mochitests in an embedding build, sadly. But the "else" branches look fine. ;)

Ok. This patch uses gBrowser to find the content windows. We're still using instanceof ChromeWindow to detect whether we've got a ChromeWindow because sometimes (due to race conditions) we see a ChromeWindow before it has a gBrowser object. In those cases, its safe to ignore the window because we'll catch it on the next call to poll().

Comment on attachment 299705 [details] [diff] [review] Updated patch for NavigationUtils.js This looks great. Thanks for doing it!

Checked in that change.