Closed Bug 1137765 Opened 10 years ago Closed 9 years ago

Intermittent browser_styleinspector_context-menu-copy-color_01.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerTimeout(N), but only as a last resort.

Categories

(DevTools :: Inspector, defect, P3)

x86
Linux
defect

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: RyanVM, Unassigned)

Details

(Keywords: intermittent-failure, Whiteboard: [btpp-backlog])

This appears to have started around the time of the other mochitest-dt issues we've been having recently. Retriggers seemed to be pointing to bug 995394 as the culprit, and it did go away for awhile post-backout. But now it's back. And it's just as inexplicable as the other ones we've been dealing with. Anyway, I'm filing the intermittent for now, but given the frequency, this bug may very-soon turn into a re-enabling bug.
Let's start with a longer timeout and see how that goes. https://hg.mozilla.org/integration/mozilla-inbound/rev/9dd9d1e5b43c
Keywords: leave-open
The test fails after all the assertions have passed, after the test harness logged "leaving test", and given the inexplicable nature of the failures we've been having, this could point in the direction of a test harness change. Bug 1073352 has recently landed, could it be related?
It's an interesting theory, but one I'm not horribly qualified to answer. Andrew, how likely does that seem to you? Basically, we're seeing lots of trunk-only timeouts on linux/linux64 debug mochitest-bc/dt. They started late last week. In some of the runs I've looked at, the DOMWINDOW count is crazy-high (like 500+), which is pretty amazing given that run-by-dir is enabled on those suites.
Flags: needinfo?(continuation)
It is certainly possible that my patch messed things up for any browser-chrome kind of test. I looked at the logs for the last two failures in this bug, and the window count doesn't go above 86, so I don't think that's a factor for this particular failure.
Flags: needinfo?(continuation)
Ryan: Do we keep the requestLongerTimeout(2) and close this bug? In the meantime, triaging as P3 (no recent failures, but that's only because of the requestLongerTimeout I guess).
Flags: needinfo?(ryanvm)
Priority: -- → P3
Whiteboard: [btpp-backlog]
Might as well at this point.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(ryanvm)
Resolution: --- → WORKSFORME
Removing leave-open keyword from resolved bugs, per :sylvestre.
Keywords: leave-open
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.