Bug 659000 added support for handling iframes with MozmillController, but it only handles the case where a window has a gBrowser. It fails to work for things like the major update window or the Thunderbird migration UI. We should figure out a way to get load events for arbitrary iframes inside a top-level window.

We're currently setting the property ourselves: https://bugzilla.mozilla.org/attachment.cgi?id=541133&action=diff#a/mail/test/mozmill/shared-modules/test-migration-helpers.js_sec1

So why is mozmillDocumentLoaded not set for sub pages? That should now be the case because in init.js we differ between tabs and HTMLDocuments. Can you please check again if you are still able to reproduce this issue? Thanks.

Because you're assuming that window.gBrowser exists at https://github.com/mozautomation/mozmill/blob/master/mozmill/mozmill/extension/resource/modules/init.js#L172. That is true for the Firefox main window but not in general.

Sorry, you aren't assuming that it exists, but what I meant is that your code that works inside tabs only works if window.gBrowser exists.

Good catch :sid0. Until recently only Firefox did have tabs. So, we need to optimize this for more general use case. So, the gBrowser is absolutely the right element for us to be using for Firefox. What should we use for thunderbird here? It's been a long time since I've reviewed the internal JS objects of the mail interface. Choice 1: This may not work: * Get window, ascertain if it has a <browser> child element ** If so, then hang our notifications off that browser DOM element. Choice 2: This will probably work: * Keep the gBrowser stuff and detect whether we're in Firefox or Thunderbird, and if in Thunderbird replace gBrowser with the proper object from Thunderbird's global JS scope. (Less cool, but will work). Choice 3: Best of all Determine what JS Object in the window contains the tab controls and use that object to hang the notifications off of. This is essentially Choice 2 with automatically detecting the proper JS object for use. Harth do you know a good JS-y way of doing this detection? This is something we'll probably have to fix on both 1.5.4 and 2.0, setting flags.

(In reply to Clint Talbert ( :ctalbert ) from comment #5) > Choice 2: This will probably work: > * Keep the gBrowser stuff and detect whether we're in Firefox or > Thunderbird, and if in Thunderbird replace gBrowser with the proper object > from Thunderbird's global JS scope. (Less cool, but will work). This would only work for the tabbrowser in thundebird but doesn't cover other windows with an embedded browser. > This is something we'll probably have to fix on both 1.5.4 and 2.0, setting > flags. Clint, do you really think that this should block 1.5.4? We have no plan how to implement that currently. And a change like that is kinda invasive as we can remember from the past. As spoken in last weeks Mozmill meeting Mozmill 1.5.4 is ready code-wise spoken. So we should better get it out soon and concentrate on a fix for this bug in 1.5.5? It would give us way more time to fully qualify its functionality.

No reason from our side to block 1.5.4 on this -- we're fine with our workaround for now. Clint: yeah, we really want to look at all <browser> elements in a window, including ones that might be added on-the-fly.

Thanks Sid! So lets bump it to 1.5.5 (when we will have one more hotfix release).

With bug 650353 landing, different chrome scopes no longer share expandos, which I think is preventing our workaround from working anymore. So Thunderbird now has a ton of failing tests. Does anybody have any cycles to work on this bug?

This bug will not be taken for version 2.1. We might want to re-evaluate for 2.2.

Mozmill will reach its end of life soon. We are currently working on getting all the tests for Firefox ported to Marionette. For status updates please see bug 1080766.