Closed Bug 573461 Opened 10 years ago Closed 8 years ago

Test failures due to non-existing window after testCloseWindow.js

Categories

(Mozilla QA Graveyard :: Mozmill Tests, defect)

x86
macOS
defect
Not set

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: aaronmt, Assigned: whimboo)

References

()

Details

(Whiteboard: [mozmill-test-failure])

Attachments

(1 file, 1 obsolete file)

MODULE: firefox\testPrivateBrowsing\testDisabledElements.js
TEST: testDisabledElements
FAIL: timeout exceeded for waitForEval('subject.privateBrowsing.enabled == subject.state')
BRANCH: 1.9.1, 1.9.2, default (trunk)
Status: NEW → ASSIGNED
That's only happening on OS X or on all platforms?
According to anthony's spreadsheet this is mac only
(In reply to comment #1)
> That's only happening on OS X or on all platforms?

Locally, I've only seen this error on Mac.  On Brasstacks, I can't find a recent non-Mac instance of this failure.
(In reply to comment #3)
> (In reply to comment #1)
> > That's only happening on OS X or on all platforms?
> 
> Locally, I've only seen this error on Mac.  On Brasstacks, I can't find a
> recent non-Mac instance of this failure.

It's because of the test that runs prior to this testCloseWindow which is mac only in the way it either a) windows or b) the way private browsing starts or stops. Looking into it.
Attached patch v1 patch (obsolete) — Splinter Review
Not sure if you want a patch for a separate test in this bug, but this patch addresses a bug that is the cause of the this reported bug's failure.
 
- Change to the handleWindow call making sure that we don't close the window after the return from the callback handler by passing true.
Attachment #452811 - Flags: review?(anthony.s.hughes)
Attached patch v1.1Splinter Review
Empty commit
Attachment #452811 - Attachment is obsolete: true
Attachment #452818 - Flags: review?(anthony.s.hughes)
Attachment #452811 - Flags: review?(anthony.s.hughes)
Comment on attachment 452818 [details] [diff] [review]
v1.1

This resolves testDisableElements.js without regressing testCloseWindow.js.  r+
Attachment #452818 - Flags: superreview?(hskupin)
Attachment #452818 - Flags: review?(anthony.s.hughes)
Attachment #452818 - Flags: review+
Comment on attachment 452818 [details] [diff] [review]
v1.1

What a silly mistake. Thanks for spotting this Aaron!
Attachment #452818 - Flags: superreview?(hskupin) → superreview+
Landed on all branches:
http://hg.mozilla.org/qa/mozmill-tests/rev/a68b9d3fc719
http://hg.mozilla.org/qa/mozmill-tests/rev/4636315319b8
http://hg.mozilla.org/qa/mozmill-tests/rev/4e76267680e2

This only a bustage fix for the moment. For a real fix we would also have to make sure that a browser window is open when the test fails while staying in private browsing mode. Right now all other tests will fail. This should be part of the teardownModule function.
Summary: [mozmill] Timeout failure in testDisabledElements.js → [mozmill] Test failures due to non-existing window after testCloseWindow.js
Mass 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.
Component: Private Browsing → Mozmill Tests
Flags: superreview+
Product: Firefox → Mozilla QA
QA Contact: private.browsing → mozmill-tests
Aaron, can you finish this bug up in the near future?
Removing assignee so this can be reassigned.
Assignee: aaron.train → nobody
Status: ASSIGNED → NEW
Summary: [mozmill] Test failures due to non-existing window after testCloseWindow.js → Test failures due to non-existing window after testCloseWindow.js
I don't see it failing any more.
I think we can call this a WONTFIX.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Please see comment 9. It states why it doesn't fail and what has to be done to completely fix this test.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
I will have a look at.
Assignee: nobody → hskupin
Status: REOPENED → ASSIGNED
So this one doesn't happen anymore. What you are seeing is a 'Timeout waiting for page loaded.' which is interesting but should be covered by another bug.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago8 years ago
Resolution: --- → WORKSFORME
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in before you can comment on or make changes to this bug.