<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Dec 13, 2014 at 8:39 AM, Mike Ratcliffe <span dir="ltr"><<a href="mailto:mratcliffe@mozilla.com" target="_blank">mratcliffe@mozilla.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">How about using executeSoon()? This is also commonly misused.<br></blockquote><div><br></div><div>Misused how?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We should also address issues where using setTimeout() should not be necessary e.g. when using node.scrollIntoView(), which is async enough to break things, especially on E10S builds. The main issue is that there is no event fired to indicate that an element has been scrolled into view.<br>
<br>
I logged <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1052109" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1052109</a> to address this some time back.<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>Yes, that would be nice.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
/Mike</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On 12/12/2014 19:47, Gavin Sharp wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
---------- Forwarded message ----------<br>
From: Ehsan Akhgari <<a href="mailto:ehsan.akhgari@gmail.com" target="_blank">ehsan.akhgari@gmail.com</a>><br>
Date: Fri, Dec 12, 2014 at 10:34 AM<br>
Subject: PSA: Flaky timeouts in mochitest-plain now fail newly added tests<br>
To: <a href="mailto:dev-platform@lists.mozilla.org" target="_blank">dev-platform@lists.mozilla.org</a><br>
<br>
<br>
We had a session on intermittent test failures in Portland <<br>
<a href="https://etherpad.mozilla.org/ateam-pdx-intermittent-oranges" target="_blank">https://etherpad.mozilla.org/<u></u>ateam-pdx-intermittent-oranges</a><u></u>>, and one of<br>
the things that we discussed was adding analyses to our test suites that<br>
detect known bad test writing practices <<br>
<a href="https://developer.mozilla.org/en-US/docs/Mozilla/QA/Avoiding_intermittent_oranges" target="_blank">https://developer.mozilla.org/<u></u>en-US/docs/Mozilla/QA/<u></u>Avoiding_intermittent_oranges</a>><br>
and fails the offending tests. As part of that effort, I just landed the<br>
patch to bug 649012 which enables this analysis on mochitest-plain.<br>
<br>
What this means for you as a test author:<br>
* Using setTimeout(foo, N); where N is not 0 will cause your tests to<br>
fail. You should double check why you're using such timeouts. They are<br>
almost never necessary.<br>
* If you have a legitimate reason for using timeouts like this (such as if<br>
your test needs to wait a bit to make sure an event doesn't happen in the<br>
future, and there is no other way of checking that), you should call<br>
SimpleTest.<u></u>requestFlakyTimeout("reason");<u></u>. The argument to the function is<br>
a string which is meant to document why you need to use these kinds of<br>
timeouts, and why that doesn't lead into intermittent test failures.<br>
<br>
What this means for you as a code reviewer:<br>
* If you see a patch which uses SimpleTest.<u></u>requestFlakyTimeout, please<br>
review the usage of timeouts carefully and make sure they are safe in the<br>
test, and the reason argument passed to that function correctly documents<br>
it.<br>
<br>
What this means for you as a module owner/peer:<br>
* I didn't have time to triage all of the existing tests that this analysis<br>
caught, so I have annotated them all with<br>
|SimpleTest.<u></u>requestFlakyTimeout("<u></u>untriaged");|. See <<br>
<a href="https://hg.mozilla.org/integration/mozilla-inbound/rev/fa8bd3194aca" target="_blank">https://hg.mozilla.org/<u></u>integration/mozilla-inbound/<u></u>rev/fa8bd3194aca</a>> for<br>
examples. Please go through the code in your module and try to triage<br>
these tests, and either fix the timeout usages, or if they are indeed OK<br>
document the reason in requestFlakyTimeout's argument. I had to do this in<br>
order to prevent new bad tests from going in as soon as possible.<br>
<br>
I have turned this on only for mochitest-plain for now, and am planning to<br>
do the same for mochitest-chrome/a11y/browser-<u></u>chrome very soon as well.<br>
<br>
Cheers,<br>
--<br>
Ehsan<br>
______________________________<u></u>_________________<br>
dev-platform mailing list<br>
<a href="mailto:dev-platform@lists.mozilla.org" target="_blank">dev-platform@lists.mozilla.org</a><br>
<a href="https://lists.mozilla.org/listinfo/dev-platform" target="_blank">https://lists.mozilla.org/<u></u>listinfo/dev-platform</a><br>
______________________________<u></u>_________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" target="_blank">https://mail.mozilla.org/<u></u>listinfo/firefox-dev</a><br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" target="_blank">https://mail.mozilla.org/<u></u>listinfo/firefox-dev</a><br>
</div></div></blockquote></div><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr">Ehsan<br></div></div>
</div></div>