Bugzilla

(In reply to Nihanth Subramanya [:nhnt11] from comment #7)

> Try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f283cc9c51b2b994088a952c2801f2094dec2755
> 
> I predict a failure due to the test taking too long; we will probably have to `requestLongerTimeout()`. This test uses `waitForCondition()` multiple times to ensure a condition *doesn't* occur, and each occurrence takes a few seconds.

So there is no failure due to it taking too long (though I wouldn't be surprised if an intermittent crops up at some point) but linux64 had a failure during the test - specifically after the first alert is shown, we reload and make sure an alert is not shown again for the same site - yet in this test, the alert was present.

I'm pretty sure this failure is due to us checking for the alert before the first one goes away when we reload - i.e. we call reload() and then start checking for the absence of the notification before the reload has actually caused the first notification to go away. I'll amend the patch and do another try push, this time with the whole test suite because Johann pointed out more failures with a similar remote-settings-fake-data test for bug 1511111.

(In reply to Nihanth Subramanya [:nhnt11] from comment #7)

> Try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f283cc9c51b2b994088a952c2801f2094dec2755
> 
> I predict a failure due to the test taking too long; we will probably have to `requestLongerTimeout()`. This test uses `waitForCondition()` multiple times to ensure a condition *doesn't* occur, and each occurrence takes a few seconds.

So there is no failure due to it taking too long (though I wouldn't be surprised if an intermittent crops up at some point) but linux64 had a failure during the test - specifically after the first alert is shown, we reload and make sure an alert is not shown again for the same site - yet in this test, the alert was present.

I'm pretty sure this failure is due to us checking for the alert before the first one goes away when we reload - i.e. we call reload() and then start checking for the absence of the notification before the reload has actually caused the first notification to go away. I'll amend the patch and do another try push, this time with ~the whole test suite~ xpcshell tests as well because Johann pointed out more failures with a similar remote-settings-fake-data test for bug 1511111.

(In reply to Nihanth Subramanya [:nhnt11] from comment #7)

> Try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f283cc9c51b2b994088a952c2801f2094dec2755
> 
> I predict a failure due to the test taking too long; we will probably have to `requestLongerTimeout()`. This test uses `waitForCondition()` multiple times to ensure a condition *doesn't* occur, and each occurrence takes a few seconds.

So there is no failure due to it taking too long (though I wouldn't be surprised if an intermittent crops up at some point) but linux64 had a failure during the test - specifically after the first alert is shown, we reload and make sure an alert is not shown again for the same site - yet in this test, the alert was present.

I'm pretty sure this failure is due to us checking for the alert before the first one goes away when we reload - i.e. we call reload() and then start checking for the absence of the notification before the reload has actually caused the first notification to go away. I'll amend the patch and do another try push, this time with ~the whole test suite~ xpcshell tests as well because Johann pointed out more failures with a similar remote-settings-fake-data test for bug 1511111.

Edit:
Here's the new try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=eab3f3f22590d6283322b237d9a1eb67c9ff6211