Closed Bug 607545 Opened 14 years ago Closed 14 years ago

Intermittent browser_bug562797.js | Test timed out *followed* by other errors

Categories

(Toolkit :: Add-ons Manager, defect)

x86
Windows Server 2003
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: philor, Assigned: robert.strong.bugs)

References

Details

(Keywords: intermittent-failure)

Attachments

(5 files, 1 obsolete file)

Attached file Fuller log snippet
There are those, boring types, who think that once a test has timed out and finished, that it should stop having errors. Not browser_bug562797.js, its creativity can't be hemmed in by those bourgeois values. http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1288143085.1288148261.10157.gz WINNT 5.2 mozilla-central debug test mochitest-other on 2010/10/26 18:31:25 s: win32-slave12 TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser/browser_bug562797.js | Test timed out TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser/browser_bug562797.js | Found a tab after previous test timed out: about:addons TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser/browser_bug562797.js | Should be on the right category - Got addons://list/extension, expected addons://list/plugin TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser/browser_bug562797.js | canGoBack should be correct - Got false, expected true TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser/browser_bug562797.js | canGoForward should be correct - Got false, expected true TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser/browser_bug562890.js | Test timed out
Contrariwise, http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1288142350.1288147634.7166.gz WINNT 5.2 mozilla-central debug test mochitest-other on 2010/10/26 18:19:10 s: win32-slave29 TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser/browser_bug562797.js | Test timed out TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser/browser_bug562797.js | Found a tab after previous test timed out: about:blank managed to time out without then failing tests after it was finished.
looking into the failure
Assignee: nobody → robert.bugzilla
Attached patch patch (obsolete) — Splinter Review
This failed consistently for me in Test 10 or Test 11. Increasing the timeout made it succeed for me consistently. btw: the debug spew had a bunch of JavaScript strict warning: chrome://mozapps/content/extensions/extensions.xml, line 1042: reference to undefined property this.mAddon.applyBackgroundUpdates JavaScript strict warning: chrome://mozapps/content/extensions/extensions.xml, line 1043: reference to undefined property this.mAddon.applyBackgroundUpdates and the mochitest log had a bunch of TEST-INFO | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser-window/browser_bug562797.js | Console message: [JavaScript Warning: "reference to undefined property this.mAddon.applyBackgroundUpdates" {file: "chrome://mozapps/content/extensions/extensions.xml" line: 1042}] TEST-INFO | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser-window/browser_bug562797.js | Console message: [JavaScript Warning: "reference to undefined property this.mAddon.applyBackgroundUpdates" {file: "chrome://mozapps/content/extensions/extensions.xml" line: 1043}] these are due to PluginProvider.jsm not having a applyBackgroundUpdates property and extensions.xml expecting all add-ons to have one.
Attachment #486444 - Flags: review?(dtownsend)
btw for onlookers tthat don't like increasing timeouts the same as me. This test opens and closes the add-ons manager window (e.g. not inside a tab) 11 times which is likely the cause of the timeout being reached on Win32 debug builds.
Comment on attachment 486444 [details] [diff] [review] patch I'd kind of prefer it if the test harness tracked the time between the ok/is calls rather than enforcing a strict whole-test timeout but here we are.
Attachment #486444 - Flags: review?(dtownsend) → review+
Just ran into this again with the fix. :( TEST-INFO | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser/browser_bug562797.js | Test 6 took 10186ms TEST-INFO | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser/browser_bug562797.js | Running test 7 TEST-PASS | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser/browser_bug562797.js | Should have an add-ons manager window TEST-PASS | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser/browser_bug562797.js | Should be displaying the correct UI TEST-INFO | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser/browser_bug562797.js | Waiting for initialization TEST-INFO | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser/browser_bug562797.js | Part 1 TEST-PASS | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser/browser_bug562797.js | Should be on the right category TEST-PASS | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser/browser_bug562797.js | Should be on the right view TEST-PASS | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser/browser_bug562797.js | canGoBack should be correct TEST-PASS | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser/browser_bug562797.js | canGoForward should be correct TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser/browser_bug562797.js | Test timed out INFO TEST-END | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser/browser_bug562797.js | finished in 91278ms TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser/browser_bug562797.js | Found a tab after previous test timed out: about:addons TEST-INFO | checking window state I suspect the lack of wait_for_view_load in Test 7 is the cause.
Comment on attachment 486444 [details] [diff] [review] patch bah, I was testing the browser-window version which took around 120 seconds... when it runs in a tab it took around 215 seconds :(
Attachment #486444 - Attachment is obsolete: true
Attachment #486444 - Flags: review+
Attached patch patch rev2Splinter Review
As I see it the options are to split up the tests or increase the timeout to a somewhat insane number. I also added a missing var and fixed the line endings for one test and fixed the logging of the pageid in another test.
Attachment #486572 - Flags: review?(dtownsend)
Comment on attachment 486572 [details] [diff] [review] patch rev2 Strange, really need to look into why the tests take so much longer in a tab. This diff seems to be broken, it claims you're changing the entire file making it difficult to review. A fixed version would be good
Mossop, see comment #15... I fixed the line endings in one of the tests when I added a missing global var.
Attachment #486572 - Flags: review?(dtownsend) → review+
fixes line endings in the tests (the reason the patch is so large), declares undeclared vars / lets, and a couple of other fixes so the tests don't report errors in debug builds.
Attachment #486708 - Flags: review?(dtownsend)
Comment on attachment 486717 [details] [diff] [review] test/browser ignore whitespace and line endings >diff -u8 -w --strip-trailing-cr ../../_mozilla-central/mozilla/toolkit/mozapps/extensions/test/browser/browser_bug557956.js toolkit/mozapps/extensions/test/browser/browser_bug557956.js >--- ../../_mozilla-central/mozilla/toolkit/mozapps/extensions/test/browser/browser_bug557956.js 2010-10-28 13:08:18 -0700 >+++ toolkit/mozapps/extensions/test/browser/browser_bug557956.js 2010-10-28 13:05:25 -0700 >@@ -97,25 +97,25 @@ > if (aAddon) > aAddon.uninstall(); > }); > aCallback(); > }); > } > > function open_compatibility_window(aInactiveAddonIds, aCallback) { >- var variant = Cc["@mozilla.org/variant;1"]. >- createInstance(Ci.nsIWritableVariant); >+ var variant = Components.classes["@mozilla.org/variant;1"]. >+ createInstance(Components.interfaces.nsIWritableVariant); > variant.setFromVariant(aInactiveAddonIds); > > // Cannot be modal as we want to interract with it, shouldn't cause problems > // with testing though. > var features = "chrome,centerscreen,dialog,titlebar"; >- var ww = Cc["@mozilla.org/embedcomp/window-watcher;1"]. >- getService(Ci.nsIWindowWatcher); >+ var ww = Components.classes["@mozilla.org/embedcomp/window-watcher;1"]. >+ getService(Components.interfaces.nsIWindowWatcher); > var win = ww.openWindow(null, URI_EXTENSION_UPDATE_DIALOG, "", features, variant); > > win.addEventListener("load", function() { > win.removeEventListener("load", arguments.callee, false); > > info("Compatibility dialog opened"); > > function page_shown(aEvent) { I started the tests and when I came back the wizard was still open so I'm going to move this change to a new bug since it might cause new orange.
Attachment #486717 - Flags: review?(dtownsend) → review+
Comment on attachment 486718 [details] [diff] [review] test/xpinstall ignore whitespace and line endings r+ and a general rs for any line-ending changes needed
Attachment #486718 - Flags: review?(dtownsend) → review+
Attachment #486708 - Flags: review?(dtownsend)
Pushed to mozilla-central minus the change noted in comment #24 http://hg.mozilla.org/mozilla-central/rev/ed3f0c6d9347 http://hg.mozilla.org/mozilla-central/rev/f92e2403e671 Leaving open to make sure the test is no longer failing
There have been a couple of runs where the test didn't timeout so resolving -> fixed.
Status: NEW → RESOLVED
Closed: 14 years ago
Flags: in-testsuite+
Flags: in-litmus-
Resolution: --- → FIXED
Hm, the latest failure from the last comment doesn't appear in the topFail list. Do we have to reopen this bug?
Unless it is from mozilla-central not it shouldn't (that was from the try server)... even if it is from mozilla-centrtal I would say no since there have been several different failures associated to an individual bug which just makes a mess of trying to find the root cause of the failure.
Oh ok, missed that. So no other failure in the last week. Marking as verified fixed.
Status: RESOLVED → VERIFIED
Is this still happening or did I miss label?
You mislabeled. The original bug was Windows specific and I was easily able to reproduce / patch it. I have no idea why Linux would experience a timeout for this test.
That'd be because Mossop gave it a call to run_next_text() for a few pushes :)
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: