Closed Bug 1050323 Opened 10 years ago Closed 10 years ago

Intermittent test_animations-dynamic-changes.html | Player state is preserved when interleaving animations in list - Player state is preserved when interleaving animations in list: assert_true: Interleaved player starts later than existing players expecte

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: emorley, Unassigned)

References

Details

(Keywords: intermittent-failure) 

Ubuntu VM 12.04 x64 Mulet b2g-inbound opt test mochitest-1 on 2014-08-06 23:49:34 PDT for push 8542bcd9ab6d

slave: tst-linux64-spot-696

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

{
00:10:07     INFO -  2712 INFO TEST-START | /tests/dom/alarm/test/test_alarm_permitted_app.html
00:10:07     INFO -  2713 INFO TEST-OK | /tests/dom/alarm/test/test_alarm_permitted_app.html | took 224ms
00:10:07     INFO -  2714 INFO TEST-START | /tests/dom/animation/test/css-integration/test_animations-dynamic-changes.html
00:10:07     INFO -  2715 INFO dumping last 1 message(s)
00:10:07     INFO -  2716 INFO if you need more context, please use SimpleTest.requestCompleteLog() in your test
00:10:07     INFO -  2717 INFO TEST-PASS | /tests/dom/animation/test/css-integration/test_animations-dynamic-changes.html |  - : Elided 4 passes or known failures.
00:10:07     INFO -  2718 INFO TEST-UNEXPECTED-FAIL | /tests/dom/animation/test/css-integration/test_animations-dynamic-changes.html | Player state is preserved when interleaving animations in list - Player state is preserved when interleaving animations in list: assert_true: Interleaved player starts later than existing players expected true got false
00:10:07     INFO -  TEST-INFO | expected PASS
00:10:07     INFO -  2719 INFO TEST-OK | /tests/dom/animation/test/css-integration/test_animations-dynamic-changes.html | took 367ms
}
I'm not sure what's causing this or why it's happening on Mulet only or why it only started recently. The only animation-related change I know of that corresponds to this timeframe is bug 996796 but that doesn't seem too likely.

I wonder if the refresh driver operates differently in Mulet and we're getting the same timestamp back even after calling requestAnimationFrame. I know when we switch internal timers we can end up reporting the same timestamp twice (since we clamp the time to make sure it doesn't go backwards).
Mass-closing intermittent-failure bugs filed by me, that have not occurred recently and do not have the leave-open keyword set.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
(In reply to Brian Birtles (:birtles) from comment #15)
> I'm not sure what's causing this or why it's happening on Mulet only or why
> it only started recently. The only animation-related change I know of that
> corresponds to this timeframe is bug 996796 but that doesn't seem too likely.
> 
> I wonder if the refresh driver operates differently in Mulet and we're
> getting the same timestamp back even after calling requestAnimationFrame. I
> know when we switch internal timers we can end up reporting the same
> timestamp twice (since we clamp the time to make sure it doesn't go
> backwards).

Do you know if this is still an issue? I'm hitting this when enabling the vsync refresh driver: https://treeherder.mozilla.org/#/jobs?repo=try&revision=ceca6ab44cce

Or whats the proper fix to this?
Flags: needinfo?(bbirtles)
Looks like you're hitting a couple of different failures than this bug.

Just looking at the first one, "Animations are removed from the start of the list while preserving the state of existing players - Animations are removed from the start of the list while preserving the state of existing players: assert_true: Remaining player preserves startTime expected true got false"

Does changing line 117 to <= fix that failure?

i.e. making the condition:

  players[0].startTime <= players[0].timeline.currentTime

If so, then I'd suggest we rewrite that test to store the startTime of one of the players before updating the CSS and checking that it doesn't change.

If, however, players[0].startTime is actually greater than players[0].timeline.currentTime then we have a problem.
Flags: needinfo?(bbirtles) → needinfo?(mchang)
Waiting on try and will retrigger - https://treeherder.mozilla.org/#/jobs?repo=try&revision=8bae6a4b2971
Flags: needinfo?(mchang)
See Also: → 1145327
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.