This past tuesday, the 1.9.2 cycle for this push... http://hg.mozilla.org/releases/mozilla-1.9.2/rev/e083b305df0c ... had Moth oranges on all three platforms, each with the exact same error: >TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/browser/components/places/tests/browser/browser_library_middleclick.js | Opened URI found in list: http://www.mozilla.com/en-US/firefox/about/ Those 3 logs are: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.6/1283884423.1283885029.25645.gz http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.6/1283883055.1283883833.20000.gz http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.6/1283882308.1283883070.16603.gz The cycle following that one had the same failure on Mac & Windows, but not on Linux. Mac & Windows logs: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.6/1283988973.1283989753.10224.gz http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.6/1283988335.1283989294.8219.gz And the cycle following *that* one had the same failure on Linux & Mac (but not on Windows): http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.6/1284152934.1284153543.28224.gz http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.6/1284149941.1284150613.14728.gz So, this is basically a new randomorange with a > 2/3 probability of failure, it seems. The "responsible" push doesn't seem like it could've been related, according to cjones... but this definitively changed from "fine" to "zomg crazy near-permaorange" on or around that push, so I don't know what's going on. CCing test-author mak, in case he has any ideas.
Note that this is similar to randomorange bug 536830, which failed at a low frequency for a few months and then became WORKSFORME. That failure had a slightly different URL than this one, though (that one had "whatismozilla.html" on the end).
can we compare the test to mozilla-central and check if it has differences?
well there are differences, some related to other oranges in central, some related to bugs that are NOT on 1.9.2... the simple short term solution is to disable the test if it's so bad, otherwise we can try to backport some of the differences.
(In reply to comment #3) > the simple short term solution is to > disable the test if it's so bad The weird thing is that the test didn't seem to be bad up until the cycle on Tuesday 9/7. (I scrolled TBPL back through the four cycles prior that one -- which covers a number of days -- and none of those earlier cycles had any instances of this failure. And now it's affected the majority of platforms for three cycles in a row. So it certainly looks like something changed to make it worse.)
maybe something changed in the box. I'll try to sync the test with central, in case of failure I'll disable it, having it working on central is enough for us.
Assignee: nobody → mak77
ok, one of the problems is that the test harness across central and 1.9.2 are completely out of sync, also waitForFocus is old and I can't properly use it, requestLongerTimeout is not even implemented. syncing test harnesses could be feasible and wanted but they now also take in count ipc and other stuff that looks not having being backported so it could be tricky.
I've disabled the test for now. http://hg.mozilla.org/releases/mozilla-1.9.2/rev/e981d93d6534 My experiments on tryserver showed that the test-harness changes are not ignorable to fix these oranges, but they are too wide purpose for this simple bug.
disabled on 1.9.1 as well. http://hg.mozilla.org/releases/mozilla-1.9.1/rev/5642fe1a6b00 Central is fine since the test there has various fixes in the test itself and in the testing harness, till it is working fine there, we are fine.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [orange] → [orange][test disabled on 1.9.1 and 1.9.2][open separate bugs for mozilla-central]
Whiteboard: [orange][test disabled on 1.9.1 and 1.9.2][open separate bugs for mozilla-central] → [test disabled on 1.9.1 and 1.9.2][open separate bugs for mozilla-central]
You need to log in before you can comment on or make changes to this bug.