Can't help but notice that bug 947170 landed around this time. Retriggering to see if the range can be narrowed down. https://tbpl.mozilla.org/php/getParsedLog.php?id=32709676&tree=Mozilla-Inbound Android 2.2 Tegra mozilla-inbound opt test mochitest-7 on 2014-01-08 10:27:16 PST for push d19f386b9061 slave: tegra-321 11289 INFO TEST-START | /tests/editor/libeditor/html/tests/test_bug612447.html 11290 INFO TEST-INFO | /tests/editor/libeditor/html/tests/test_bug612447.html | must wait for load 11291 INFO TEST-PASS | /tests/editor/libeditor/html/tests/test_bug612447.html | Typing should work 11292 INFO TEST-PASS | /tests/editor/libeditor/html/tests/test_bug612447.html | The editor commands should work 11293 INFO TEST-PASS | /tests/editor/libeditor/html/tests/test_bug612447.html | Typing should work 11294 INFO TEST-PASS | /tests/editor/libeditor/html/tests/test_bug612447.html | The editor commands should work 11295 INFO TEST-PASS | /tests/editor/libeditor/html/tests/test_bug612447.html | The iframes should look the same before typing 11296 INFO TEST-PASS | /tests/editor/libeditor/html/tests/test_bug612447.html | The iframes should look the same after typing 11297 INFO TEST-INFO | MEMORY STAT vsize after test: 609153024 11298 INFO TEST-INFO | MEMORY STAT residentFast after test: 162463744 11299 INFO TEST-INFO | MEMORY STAT heapAllocated after test: 42375244 11300 INFO TEST-END | /tests/editor/libeditor/html/tests/test_bug612447.html | finished in 608ms 11301 INFO TEST-START | /tests/editor/libeditor/html/tests/test_bug622371.html 11302 ERROR TEST-UNEXPECTED-FAIL | /tests/editor/libeditor/html/tests/test_bug622371.html | The start offset of the selection shouldn't change - got 0, expected 1 11303 ERROR TEST-UNEXPECTED-FAIL | /tests/editor/libeditor/html/tests/test_bug622371.html | The end offset of the selection shouldn't change - got 0, expected 1 11304 INFO TEST-INFO | MEMORY STAT vsize after test: 604463104 11305 INFO TEST-INFO | MEMORY STAT residentFast after test: 155684864 11306 INFO TEST-INFO | MEMORY STAT heapAllocated after test: 34245788 11307 INFO TEST-END | /tests/editor/libeditor/html/tests/test_bug622371.html | finished in 426ms
Retriggers are strongly pointing to the landing of bug 940229 as when this started. Running a backout of that through Try to hopefully confirm. https://tbpl.mozilla.org/?tree=Try&rev=98dbcdee471d
(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #5) > Retriggers are strongly pointing to the landing of bug 940229 as when this > started. That bug just added a single mochitest, test_extra_inherit_initial.html, and that test is in a completely different batch of mochitests. (This issue is in mochitest-7, whereas test_extra_inherit_initial.html is in mochitest-8. For proof, here's a link to the mochitest-8 log from comment 1's push: https://tbpl.mozilla.org/php/getParsedLog.php?id=32717641&tree=B2g-Inbound ) So I don't see how it's possible that bug 940229 could be responsible, aside from perhaps that it made us reshuffle which existing tests fall into which buckets (as any mochitest-addition would do, IIUC).
I've got 30 green runs on the push prior to yours, and yours hit it in 2/10.
I can also confirm that test_bug622371.html is running in mochitest-7 in that run too.
(In reply to Daniel Holbert [:dholbert] from comment #6) > That bug just added a single mochitest, test_extra_inherit_initial.html Technically, bug 940229 also added a few values to some lists in property_database.js. It's conceivable that these tweaks could've modified the behavior of tests that use property_database.js. However, libeditor/html/tests/test_bug622371.html doesn't use property_database.js, so that can't be the problem. (In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #8) > I can also confirm that test_bug622371.html is running in mochitest-7 in > that run too. Thanks -- I wasn't necessarily suggesting that we shifted test_bug622371.html from one bucket to another, but more that we might've shifted *another* problematic test into (or out of) mochitest-7, and that affected test_bug622371.html's behavior somehow. Seems like a stretch, but it's more conceivable than test_extra_inherit_initial.html (in a different mochitest bucket) affecting test_bug622371.html's behavior. That's the only conceivable way I could imagine bug 940229 triggering this.
55 green runs on the push prior and 50 green runs on the Try backout. With our Orange Factor currently sitting around 8, maybe it's best to just backout for now?
Works for me. (Though I'm a bit mystified.) If the backout fixes it, I can sort it out on Try before re-landing.
Can you look at the list of tests in the logs to see if the landing pushed a test between mochitest sets? If so, can adding a dummy test elsewhere push it back until further investigation figures out what's up?
It looks like dom/tests/mochitest/general/test_clientRects.html was removed from the start of mochitest-7 and js/xpconnect/tests/mochitest/test_bug691059.html was added to the end of mochitest-7.
Though it seems a little more interesting that test_clipboard_events.html is now the first test in the mochitest-7 run whereas it wasn't the first test before. (Just because that seems slightly more related.)
And, for reference, the tbpl links for the regression range are: before: https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=82cd92e10736 after: https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=53aedd08699f
Didn't have time to look into Comment 14 tonight, but FWIW: Here's a Try run with unmodified mozilla-inbound tip as of a few hours ago, with just mochitest-7 and mochitest-8 on Android (it has 12 green M-7 runs on Android-2.2 so far, with more queued... I'm expecting it to hit some instances of this bug eventually): https://tbpl.mozilla.org/?tree=Try&rev=a6b6656fc6b7 And (assuming that^ eventually turns orange) here's a Try run with test_extra_inherit_initial.html removed from the mochitest.ini, which would be one possible temporary-workaround for this issue: https://tbpl.mozilla.org/?tree=Try&rev=1e156f604946 If the first Try run hits this orange and the second does not, then that'll confirm that it is indeed just the test list modification that caused this.
(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #7) > I've got 30 green runs on the push prior to yours, and yours hit it in 2/10. Interestingly, the first Try run from comment 18 (unmodified mozilla-inbound, including bug 940229's patches and hence expected-to-be-orange) has now 34 completed M-7 runs on Android-2.2 now, all of them green. So: it looks like this might have fixed itself, or something. If we can't make that Try run go orange, then maybe it means this issue only affects builds that were generated during a certain window of time, due to a build toolchain quirk, or an infra change, or something like that... (?)
That first Try run from comment 18 now has 68/68 green M-7 runs. So, it's looking like m-i has been cured of this, somehow. (BTW: I suspected that maybe this became fixed simply by someone inserting or removing another mochitest, which would potentially have offset the one that I added & rebalanced the mochitest-batches. That's not the case, though -- at least, the broken "after" TBPL cycle from comment 16 has the same same starting and ending tests (test_clipboard_events.html - test_bug691059.html) as the (not-broken) first Try run in comment 18.)
So unless we get more reports here, I guess this is WORKSFORME for the time being. I'll wait a day or so before resolving it. --> setting needinfo=me so I remember.
This test has once again demonstrated its flakiness. Skipping on Android until "someone" can look at it in greater details. https://hg.mozilla.org/integration/fx-team/rev/c24edbc71fbc
And because it's been one of *those* weeks, really disable it this time. https://hg.mozilla.org/integration/fx-team/rev/f5d04ca4795d
Bulk assigning P3 to all open intermittent bugs without a priority set in Firefox components per bug 1298978.