Closed Bug 920570 Opened 11 years ago Closed 11 years ago

Intermittent browser_codemirror.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 :: Source Editor, defect, P1)

Product:
DevTools
Component:
Source Editor
Type:
defect

Tracking

(firefox26 unaffected, firefox27 fixed, firefox28 fixed, firefox-esr24 unaffected)

Status:
RESOLVED FIXED
Milestone:
Firefox 28
Tracking Flags:
Tracking Status
firefox26 --- unaffected
firefox27 --- fixed
firefox28 --- fixed
firefox-esr24 --- unaffected

People

(Reporter: miker, Assigned: anton)

References

Details

(Keywords: intermittent-failure)

Seems like we probably need to use requestLongerTimeout() here because this test runs all of codemirror's tests.
Summary: TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/devtools/sourceeditor/test/browser_codemirror.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerTimeout(N), but on → Intermittent TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/devtools/sourceeditor/test/browser_codemirror.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerTimeo
Summary: Intermittent TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/devtools/sourceeditor/test/browser_codemirror.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerTimeo → Intermittent browser_codemirror.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.
Blocks: 912260
Between this and bug 920876, I'm unable to tell the difference between the current state and this test being permaorange, which means there's very little point in continuing to run it.
Agreed; skipped on linux: remote: https://hg.mozilla.org/integration/fx-team/rev/8c2d93bcb585
Whiteboard: [test disabled on linux] [leave open]
Yeah, we can disabled it until I'm done with my current project (any day now). Then I will break that test up.
Assignee: nobody → anton
Seems like all failures were on Linux. How underpowered are our Linux machines? :) I'm building Nightly on my virtual machine right now to see if there's anything particularly slow about it. I looked into splitting tests. Most CodeMirror tests are concentrated in one file and I'd rather not touch it since we'd like to preserve original files for easier upgrades. I think requesting longer timeout is the way to go here. So unless I find something specific on Linux that slows tests down *or* someone more knowledgeable has an opinion, I will add requestLongerTimeout, re-enable that test on Linux and see what happens.
The Linux test slaves are basically never the "the slaves are just too slow" platform; they are, however, quite frequently the "gack, that thing that you would totally expect to work on all our platforms doesn't actually work on Linux" platform. And now that they are Amazon VMs, there's a little more scope for them being surprising than there was before. However, that also makes it even easier than it ever was before for releng to give you access to a loaner where you can run it and have it fail just like it was in production.
Played with a Fedora loaner today all day and couldn't reproduce the timeout even once. That said, the average for all runs was around 25 seconds which is pretty close to the default timeout value, if I'm not mistaken. So I think requestLongerTimeout is a way to go. Phil, do you have any objections?
Flags: needinfo?(philringnalda)
It wasn't me who wrote the timeout message saying to only use requestLongerTimeout as a last resort, but I certainly agree with the sentiment: browser-chrome takes an insanely long time to run as it is. So, while I agree that it probably just mostly takes 32 or 33 seconds to run on Linux, *why*? Linux is not our slowest platform, for the most part it's our fastest. Yet for this one test, which runs in 20 seconds on WinXP debug (which is our slowest platform by far), we need more than 30 seconds on Linux. Why? What is it doing during that time, and does it actually need to be doing it, and does it need to be doing it that way?
Flags: needinfo?(philringnalda)
I do agree with the sentiment but here we have imported tests for CodeMirror. They weren't written with Firefox and its test systems in mind and I'd rather not modify them because every modification we make to the CodeMirror source complicates any further upgrades. I'll see what other options we have before requesting longer timeout but that might be the only solution (other than rewriting CM tests, of course)
Priority: -- → P1
Requested longer timeout and re-enabled test on Linux: https://hg.mozilla.org/integration/fx-team/rev/867ba794e043 Let's see what happens.
No new failures since it got merged to central two days ago. Since before that it was almost a perma-orange I assume it got fixed. I'll re-open if new failures get starred.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [test disabled on linux] [leave open]
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.