http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1283281669.1283282620.19640.gz Rev3 Fedora 12 mozilla-central opt test mochitests-3/5 on 2010/08/31 12:07:49 s: talos-r3-fed-025 5608 INFO TEST-PASS | /tests/dom/tests/mochitest/general/test_offsets.xul | svgrect scrollTop after nonscroll - 0 should equal 0 5609 ERROR TEST-UNEXPECTED-FAIL | /tests/dom/tests/mochitest/general/test_offsets.xul | Test timed out. There's a screenshot in the log, but it doesn't seem to show any smoking guns.

It seems like this happened first on http://hg.mozilla.org/mozilla-central/rev/fdf35ea63a85. The only relevant changeset pushed a short while before that is dbaron's bug 585715...

It's not clear to me why my changes would be relevant, especially for the test timing out. That seems more likely to be related to the popup stuff it does, perhaps? In any case, I ran the test under valgrind and didn't see any warnings (though I probably should have tried with the pres arena turned off as well).

Comment 40 isn't this, it was a backed-out patch.

Bug 615546 supposedly made this bug happen more often...

Your self-invented scheme for summaries doesn't actually help anything.

(In reply to comment #47) > Bug 615546 supposedly made this bug happen more often... Confirmed. Normal -> Major: as this prevents landing that harness fix. Unless we disable this test until it is fixed? (In reply to comment #49) > Your self-invented scheme for summaries doesn't actually help anything. At least, it helps (me) to easily know which test suite is affected... What harm does that do?

Adding random visual noise to summaries makes it harder to spot the only two things that matter, the test name and the failure message, when multiple bugs are suggested in tbpl. And "mochitest-n" is nothing but noise - which chunk of mochitest it's in isn't decided at birth, it's just a function of how many tests there are in what directories. That's like saying "my car was stolen, the guy drove away in the right lane, so look for it in the right lane."

Ftr, This test was added in http://hg.mozilla.org/mozilla-central/rev/2e8dfe209f09 "Add clientXXX and scrollXXX properties to XUL elements, also add width/height properties to ClientRect" Passing log examples: Linux and Windows: { svgrect scrollTop after nonscroll - 0 should equal 0 outerpopup scrollLeft - 0 should equal 0 } MacOSX: (which has extra checks) { svgrect scrollTop after nonscroll - 0 should equal 0 popup before open scrollLeft - 0 should equal 0 popup before open scrollTop - 0 should equal 0 popup before open scrollWidth - 0 should equal 0 popup before open scrollHeight - 0 should equal 0 popup before open clientLeft - 0 should equal 0 popup before open clientTop - 0 should equal 0 popup before open clientWidth - 0 should equal 0 popup before open clientHeight - 0 should equal 0 outerpopup scrollLeft - 0 should equal 0 } And the test usually passes in 1-2 seconds. Timeouts are always _after_ passing "svgrect scrollTop after nonscroll". *** I don't see anything obviously wrong. Then, I'll Try 1-2 guess(es) I have...

(In reply to comment #52) > I don't see anything obviously wrong. > Then, I'll Try 1-2 guess(es) I have... None of my guesses worked. Fwiw, { - onpopupshown="testElements('outermenu', doneTests)"> + onpopupshown="setTimeout(testElements, 0, 'outermenu', doneTests);"> } made no difference. *** From the debug logs, it seems the "hang" happens during/after |$("outermenu").open = true;|: some DOCSHELL+DOMWINDOW releases happen, then/but the second part of the test doesn't start. *** (In reply to comment #120) > http://hg.mozilla.org/mozilla-central/rev/36d993e97158 It seems this s/setTimeout/waitForFocus/ when the test starts didn't help. Could the test be losing focus while it runs? Can anyone reproduce this failure locally? (To confirm what is (not) happening.)

(In reply to comment #51) > Adding random visual noise to summaries makes it harder to spot the only two > things that matter, the test name and the failure message, when multiple bugs > are suggested in tbpl. Hum, TBPL is not the only tool... > And "mochitest-n" is nothing but noise - which chunk of > mochitest it's in isn't decided at birth, it's just a function of how many > tests there are in what directories. That's like saying "my car was stolen, the > guy drove away in the right lane, so look for it in the right lane." It can be useful to have this data in (some) BugZilla search results, for example...

(In reply to comment #50) > Unless we disable this test until it is fixed? At least, you could add some "dump()" in doneTests() and the 2 onpopupshown() to narrow down were the test hangs exactly...