All users were logged out of Bugzilla on October 13th, 2018
With bug 775811 fixed we now start Mozmill early in the start-up process. This works fine in opt builds but fails in debug builds as I have seen now while debugging bug 786852. Startup takes a long time for debug builds and the first top-level window will show-up way later. But Mozmill wants to directly start the test instead of waiting for the first top-level window. We have to make sure that this will not happen. It shouldn't be too hard to implement.
Whiteboard: [mozmill-2.0?] → [mozmill-2.0+]
Assignee: hskupin → nobody
Whiteboard: [mozmill-2.0+] → [mozmill-2.1?]
As it looks like our initial window handling code for top-level windows is broken and can result in inconsistent results where we assume a window has already been finished loading. This will break the first test with a failure like: "message": "this.docShell is null", "fileName": "chrome://global/content/bindings/browser.xml", "name": "TypeError", "lineNumber": 323 To prevent this we cannot assume the window is already loaded but have to take the current value of the document's readyState.
Assignee: nobody → hskupin
Whiteboard: [mozmill-2.1?] → [mozmill-2.0?]
Summary: Debug builds cause Mozmill to fail because no top-level window has been opened yet → Slowly opened top-level windows cause failures on startup because we assume those are already loaded
Created attachment 741862 [details] [diff] [review] Patch v1
Attachment #741862 - Flags: review?(ctalbert)
Comment on attachment 741862 [details] [diff] [review] Patch v1 Review of attachment 741862 [details] [diff] [review]: ----------------------------------------------------------------- Good catch. r=me
Attachment #741862 - Flags: review?(ctalbert) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whiteboard: [mozmill-2.0?] → [mozmill-2.0]
Whiteboard: [mozmill-2.0] → [mozmill-2.0][ateamtrack: p=mozmill q=2013q2 m=1]
You need to log in before you can comment on or make changes to this bug.