Investigate speeding up /tests/layout/generic/test/test_bug514732.html




7 years ago
7 years ago


(Reporter: jgriffin, Unassigned)


(Blocks: 1 bug)


Firefox Tracking Flags

(Not tracked)




7 years ago
As part of the BuildFaster project (see, we are investigating whether certain slow mochitests can be sped up.

test_bug514732.html is a slow test, average execution time on a recent run (in ms):

	win32-debug, 31787
	linux-opt, 28768
	macosx64-debug, 32499
	win32-opt, 28822
	linux64-opt, 28784
	linux64-debug, 32147
	macosx-debug, 32645
	linux-debug, 32267

Comment 1

7 years ago
Roy, as the original author of this test, would you be willing to help see if the execution time of this test could be improved?
(In reply to comment #1)

This test modifies the page and tests (a) that a specific event is fired when we expect it to be, and (b) that this event is not fired when we expect it not to be.  For (b), in order to be sure that an event is not fired, the test waits around for a few seconds before continuing.  I'm fairly certain that these waiting periods are what you're measuring when you see that the test is consistently slow.

In file_bug514732_helper.html, the JS function waitInterrupt sets this waiting period to 3500 milliseconds (see the argument to setTimeout).  I seem to recall thinking that this was a rather inexcusably high value, but that we still brought it up there in order to prevent random oranges at the time.  (The waiting period used to be 1200 milliseconds, which isn't that much better.)  This change occurs in revision e67094febf72, in response to bug 527872.
You need to log in before you can comment on or make changes to this bug.