Closed Bug 1305368 Opened 5 years ago Closed 5 years ago

[e10-multi] Lot's of "This test exceeded the timeout threshold. It should be rewritten or split up." failures with multiple content process


(Core :: DOM: Content Processes, defect)

Not set





(Reporter: gkrizsanits, Unassigned)


(Depends on 1 open bug)


(Whiteboard: [e10s-multi:M1])

Many of the test fails because timeouts on ash. I investigated this and similarly to the tab close timeouts opening new tabs (and loading some content in them) became significantly slower in browser chrome test (2,5x slower). So a bunch of tests that are already intermittently times out with this message turns perma orange, and some of the tests that already doing requestLongerTimeout should be bumped up to call it with a bigger number.

I'm not sure if it's an acceptable fix even for temporarily. But we have to talk this over during our next meeting. In the meanwhile I will try to do some more measurements.

I checked if this comes from the shim layer that comes with browser chrome tests, but no, waiving the shim layer does not help.

If we have multiple content process than opening a new tab starts a new process so that is expected to be slower, the weird thing however is the many WARNING: pipe error: Broken pipe: on the console.

If we force single content process for a test, before the test would start the browser chrome test suite opens and closes some windows/tabs during init (when the multi process is still enabled) which starts and kills a couple of content processes, which results in the same Broken pipe warnings and probably related to that slows down the test in the beginning.
Blocks: e10s-multi
Whiteboard: [e10s-multi:?]
We'll have to make a decisions here about how we want to progress with this issue, I'm setting the needinfo flag just to make sure we won't forget to talk this over.
Flags: needinfo?(mrbkap)
So I've simulated the browser chrome test utils, and opened a tab, loaded an uri from a local http server and the closed the tab a few times. With the profiler attached this is the result (note that this is a debug build):

It seems like the content process at startup spending long seconds in the SDK's loader (

I'll continue from here tomorrow.
Flags: needinfo?(mrbkap)
Whiteboard: [e10s-multi:?] → [e10s-multi:M1]
Depends on: 1308860
Depends on: 1308867
Depends on: 1308332
Depends on: 1308895
Depends on: 1317304
Bug 1308895 fixed this so I'm closing this for now.
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.