Intermittent layout/base/tests/test_bug588174.html | Second listener should fire after first listener

RESOLVED FIXED in Firefox 28

Status

()

defect
P5
normal
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: RyanVM, Assigned: avih)

Tracking

({intermittent-failure})

Trunk
mozilla30
x86
Windows 7
Points:
---

Firefox Tracking Flags

(firefox28 fixed, firefox29 fixed, firefox30 fixed, firefox-esr24 unaffected, b2g-v1.3 fixed, b2g-v1.3T fixed, b2g-v1.4 fixed)

Details

(Whiteboard: [qa-])

Attachments

(1 attachment)

Possible timing issue?

https://tbpl.mozilla.org/php/getParsedLog.php?id=23733888&tree=Mozilla-Inbound

Windows 7 32-bit mozilla-inbound debug test mochitest-4 on 2013-06-03 14:47:13 PDT for push 281b0297de65
slave: t-w732-ix-098

14:53:15     INFO -  17599 INFO TEST-START | /tests/layout/base/tests/test_bug588174.html
14:53:15     INFO -  ++DOMWINDOW == 215 (0CAF9368) [serial = 2155] [outer = 05A58A28]
14:53:16     INFO -  17600 INFO TEST-PASS | /tests/layout/base/tests/test_bug588174.html | Bogus animation start time
14:53:16     INFO -  17601 INFO TEST-PASS | /tests/layout/base/tests/test_bug588174.html | First listener should fire after start
14:53:16     INFO -  17602 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/base/tests/test_bug588174.html | Second listener should fire after first listener
14:53:16     INFO -  17603 INFO TEST-END | /tests/layout/base/tests/test_bug588174.html | finished in 194ms
Possible, in theory, but seems really really fishy!  I guess if we got serious clock skew (like of the "running backwards" variety).
Avi, Avi, he's our man. If he can't do it no-one can!
Flags: needinfo?(avihpit)
Heh, I was merely a proxy on previous issues ;)

Anyway, this could be related to bug 858737 (same error description). That bug was rare but persistent, and it got worked-around rather than actually fixed.

But this bug at least has a much clearer timeline: started around early-mid June and been relatively consistent and mildly frequent since.

Also, it doesn't seem slave-specific.

I don't recall a timing change around the beginning of June.

Honza?
Flags: needinfo?(avihpit)
(I should be able to better handle mid-air bugzilla collisions without losing details which were already entered once).
Flags: needinfo?(honzab.moz)
(In reply to Avi Halachmi (:avih) from comment #36)
> Anyway, this could be related to bug 858737 ...

It's more than related. It's an identical test case and test, with the only difference that this test (test_bug588174.html) has one variable renamed for better readability (t->time).

This raises 2 questions:

1. Why is the fail pattern here different than that of bug 858737? (this failed much more frequently before we worked-around bug 858737). To me it seems more than luck, but I can't think of a concrete reason. Maybe one of the tests runs more frequently or on different cases?

2. What would be the best practice (files/naming wise etc) for the same testcase which tests 2 different features? (test_bug569520.html: support rAF, test_bug588174.html: support callback arg in rAF). Surely, if a testcase proves problematic, we'd want to fix all its instances, but there was nothing linking these 2 tests other than one being a copy of the other.
Flags: needinfo?(honzab.moz) → needinfo?(bzbarsky)
> It's an identical test case and test

Oh, fun.

They used to be different back when test_bug569520.html tested the no-argument form of mozRequestAnimationFrame.  But when we removed that in 704171 we apparently updated test_bug569520.html to use the one-arg form in the obvious way... and since test_bug588174.html was initially created by copying test_bug569520.html and updating it to use the one-arg form (when it was added as a test for the one-arg form), we ended up with two identical test files.  ;)

> To me it seems more than luck

I suspect it's luck.

> What would be the best practice (files/naming wise etc) for the same testcase which
> tests 2 different features?

test_requestAnimationFrame, test_requestAnimationFrameWithCallback?
Flags: needinfo?(bzbarsky)
Priority: -- → P5
Well, seems this bug is back. I'll fix it.
Bug 858737 had identical source code and intermittent failures as this. Applying the same fix here: making test_bug588174.html and test_bug569520.html identical again.
Assignee: nobody → avihpit
Attachment #8378260 - Flags: review?(bzbarsky)
Comment on attachment 8378260 [details] [diff] [review]
Add some slack to test_bug588174.html

r=me
Attachment #8378260 - Flags: review?(bzbarsky) → review+
https://hg.mozilla.org/mozilla-central/rev/485ec336ffff
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
Whiteboard: [qa-]
(In reply to TBPL Robot from comment #123)
> RyanVM
> https://tbpl.mozilla.org/php/getParsedLog.php?id=36175212&tree=Mozilla-B2g26-
> v1.2
> Windows XP 32-bit mozilla-b2g26_v1_2 opt test mochitest-4 on 2014-03-14
> 18:08:45
> revision: 35a1e0eb3275
> slave: t-xp32-ix-059
> 
> 18259 ERROR TEST-UNEXPECTED-FAIL |
> /tests/layout/base/tests/test_bug588174.html | Second listener should fire
> after first listener


This doesn't include the fix: https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/annotate/35a1e0eb3275/layout/base/tests/test_bug588174.html
See Also: → 1053902
You need to log in before you can comment on or make changes to this bug.