Not sure which change exactly caused us to fail when acting on content elements but bug 503277 made it definitely visible. All documents which are returned by controller.tabs.activeTab are wrapped and that's the reason why elements defined before a page load cannot be accessed afterward. The wrapped object has been replaced and the document is simply not existent anymore. I will have to investigate all possible areas were unwrapping of the document has to take place. This should block Mozmill 1.5.1.

Ok, after some more investigation my initial comment was not correct. Elements from content shouldn't be unwrapped in all cases because that can open security wholes. There is a much broader problem involved with page loading which I have opened for discussion here: http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/b86fe14e388cb92c# Lets stick this bug for the waitForPageLoad case. That means the following things have been taken care on the upcoming patch: * We shouldn't set custom properties to a XPCNativeWrapper object. In our case it will be the HTMLDocument node which is wrapped. Instead the documentLoaded property should be set to the browser itself. This node is not wrapped because its in chrome space. It's identical to the window.documentLoaded property. * Searching for the tab can be made 100% safe by using window.gBrowser.getBrowserForDocument. Comparing the browser nodes returns the correct tab node. Comparing the HTMLDocuments is faulty because of the above mentioned issue. * There was a bug which always has used the active tab, even when another one has been specified. That slipped through our both fingers on bug 604878. :/

Also fix the remaining script warnings when documentLoaded hasn't been set yet.

Landed as: https://github.com/mozautomation/mozmill/commit/d54cf977d2968de18e60d3bc0a30e9ddd18bb712 (master) https://github.com/mozautomation/mozmill/commit/042b289e9c1afba74ba406cad126f16fcebe46d1 (hotfix-1.5.1)