This test fails with: could not find element XPath: /html/body

Assigning to myself. I'll attempt to fix all security failures this quarter.

When fixing this please also keep in mind to add some code to teardownModule which will absolutely close this popup if it is still open.

The problem here is that the test tries to click on a blank content area to dismiss the identity popup. However, if previous tests don't clean up properly and a window is left behind, the click event happens on the rogue window, and not the content window (resulting in the failure). For example, if the prefs dialog is still up the test will try to find an "/html/body" element in the prefs dialog to click on. It doesn't exist so the test fails. Henrik, please advise on the following solution... Currently we do this: var popup = new elementslib.ID(controller.window.document, "identity-popup"); // Click inside the content area to close the popup var contentArea = new elementslib.XPath(controller.tabs.activeTab, "/html/body"); controller.click(contentArea); // Check the popup state controller.waitForEval("subject.state == 'closed'", gTimeout, 100, popup.getNode()); We can do this instead: var popup = new elementslib.ID(controller.window.document, "identity-popup"); // Press ESC to dismiss the popup controller.keypress(popup, 'VK_ESCAPE', {}); // Check the popup state controller.waitForEval("subject.state == 'closed'", gTimeout, 100, popup.getNode()); This will always pass because the pop-up is the most recent window and pressing ESC is a completely legitimate way to dismiss this dialog. Pressing ESC will always dismiss this window, even in cases where rogue windows are left behind by dirty-tests. If this is a valid solution to you, Henrik, I suggest we also implement this in teardownModule() as insurance. If this is not a valid solution, please advise on a better solution. Thanks.

Well, we can use ESC but we should also check for a click. Why can't we simply click again on the identity button? It's the same area we clicked on to open the popup so we should be safe.

(In reply to comment #4) > Well, we can use ESC but we should also check for a click. Why can't we simply > click again on the identity button? It's the same area we clicked on to open > the popup so we should be safe. This would certainly work in the test. My concern for teardownModule() is that if we add a click to ensure this is closed but it's already closed, it will result us ending the test with the popup open. In other words, an ESC is always CLOSE, a CLICK is sometimes OPEN sometimes CLOSE. I'd be open to clicking this in the test and then using ESC to ensure that the popup is closed in teardown.

Well, we should check if the popup is open before we hit ESC or click the favicon again. The popup has a property for its visibility state. That way we can make sure to not open it accidentally again. In teardownModule we should even use the hard way with .close() which should be available.

Is this failure still occuring? Last update in June

(In reply to comment #8) > Is this failure still occuring? Last update in June nm, read whiteboard

This particular failure has been fixed by bug 604832, but there is still one failure for Ubuntu with Shiretoko builds. Could be related to focus issues. Lets get a new bug filed on that.

Move of Mozmill Test related project bugs to newly created components. You can filter out those emails by using "Mozmill-Tests-to-MozillaQA" as criteria.