The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d0d8656edac7575ef7e95f778084970b6e47c261

commit d0d8656edac7575ef7e95f778084970b6e47c261
Author: sergiyb <sergiyb@chromium.org>
Date: Fri Mar 11 06:50:13 2016

Disable web-animations-api/animation-state-changes-negative-playback-rate.html as flaky

TBR=tansell@chromium.org
BUG= 593982 

Review URL: https://codereview.chromium.org/1786523002

Cr-Commit-Position: refs/heads/master@{#380560}

[modify] https://crrev.com/d0d8656edac7575ef7e95f778084970b6e47c261/third_party/WebKit/LayoutTests/TestExpectations

Fixing component name after Monorail migration

This flake is a test for the web-animations-api in a test that dstockwell@ added (according to blame on https://chromium.googlesource.com/chromium/src/+blame/master/third_party/WebKit/LayoutTests/web-animations-api/animation-state-changes-negative-playback-rate.html). I'm adding suzyh@ who is the current lead for the web-animations-api team to triage.

sergiyb@ Any idea how / when this got assigned to me? I'm guessing it was due to being associated with LayoutTests and animations. The history log in monorail doesn't seem to include the assignment step?

Checking the results of the test on the flakiness dashboard, I'm seeing failures like

FAIL running assert_equals: expected 100000 but got 99999.99999999999
FAIL running -> pause() assert_equals: expected 100000 but got 99999.99999999999
FAIL running -> reverse() assert_equals: expected 0 but got 99999.99999999999
FAIL running -> play() assert_equals: expected (number) 100338.7040000007 but got (object) null

WebKit Linux non-Oilpan (dbg) is also showing a crash

crash log for renderer (pid <unknown>):
STDOUT: <empty>
STDERR: [4:4:0310/214703:12313874757:FATAL:watcher.cc(99)] Check failed: result == MOJO_RESULT_OK (3 vs. 0)
STDERR: #0 0x7fe83b58175e base::debug::StackTrace::StackTrace()
STDERR: #1 0x7fe83b5e1d3f logging::LogMessage::~LogMessage()
STDERR: #2 0x7fe83c375b2e mojo::Watcher::Cancel()
STDERR: #3 0x7fe83e74a4c0 mojo::edk::js::WaitingCallback::Cancel()
STDERR: #4 0x7fe83e74a727 mojo::edk::js::WaitingCallback::~WaitingCallback()
STDERR: #5 0x7fe83e74a789 mojo::edk::js::WaitingCallback::~WaitingCallback()
STDERR: #6 0x7fe838f2ec0f gin::WrappableBase::SecondWeakCallback()
STDERR: #7 0x7fe83864f6b5 v8::internal::GlobalHandles::PendingPhantomCallback::Invoke()
STDERR: #8 0x7fe83864f5d9 v8::internal::GlobalHandles::InvokeSecondPassPhantomCallbacks()
STDERR: #9 0x7fe838654497 v8::internal::GlobalHandles::PendingPhantomCallbacksSecondPassTask::RunInternal()
STDERR: #10 0x7fe83821d3f9 v8::internal::CancelableTask::Run()
STDERR: #11 0x7fe838f19c89 _ZN4base8internal15RunnableAdapterIMN3gin5TimerEFvvEE3RunIJEEEvPS3_DpOT_
STDERR: #12 0x7fe838f19bf9 _ZN4base8internal12InvokeHelperILb0EvNS0_15RunnableAdapterIMNS_5TimerEFvvEEEE8MakeItSoIJPS3_EEEvS6_DpOT_
STDERR: #13 0x7fe838f2e9a5 _ZN4base8internal7InvokerINS_13IndexSequenceIJLm0EEEENS0_9BindStateINS0_15RunnableAdapterIMN2v84TaskEFvvEEEFvPS7_EJNS0_12OwnedWrapperIS7_EEEEENS0_12InvokeHelperILb0EvSA_EEFvvEE3RunEPNS0_13BindStateBaseE
STDERR: #14 0x7fe83b56107e base::Callback<>::Run()
STDERR: #15 0x7fe83b58714e base::debug::TaskAnnotator::RunTask()
STDERR: #16 0x7fe835201a32 scheduler::TaskQueueManager::ProcessTaskFromWorkQueue()
STDERR: #17 0x7fe8351ff9b2 scheduler::TaskQueueManager::DoWork()
STDERR: #18 0x7fe83520717e _ZN4base8internal15RunnableAdapterIMN9scheduler16TaskQueueManagerEFvNS_9TimeTicksEbEE3RunIJRKS4_RKbEEEvPS3_DpOT_
STDERR: #19 0x7fe83520707a _ZN4base8internal12InvokeHelperILb1EvNS0_15RunnableAdapterIMN9scheduler16TaskQueueManagerEFvNS_9TimeTicksEbEEEE8MakeItSoINS_7WeakPtrIS4_EEJRKS5_RKbEEEvS8_T_DpOT0_
STDERR: #20 0x7fe835206ff8 _ZN4base8internal7InvokerINS_13IndexSequenceIJLm0ELm1ELm2EEEENS0_9BindStateINS0_15RunnableAdapterIMN9scheduler16TaskQueueManagerEFvNS_9TimeTicksEbEEEFvPS7_S8_bEJNS_7WeakPtrIS7_EERS8_bEEENS0_12InvokeHelperILb1EvSB_EEFvvEE3RunEPNS0_13BindStateBaseE
STDERR: #21 0x7fe83b56107e base::Callback<>::Run()
STDERR: #22 0x7fe83b58714e base::debug::TaskAnnotator::RunTask()
STDERR: #23 0x7fe83b5feaff base::MessageLoop::RunTask()
STDERR: #24 0x7fe83b5fed88 base::MessageLoop::DeferOrRunPendingTask()
STDERR: #25 0x7fe83b5fef52 base::MessageLoop::DoWork()
STDERR: #26 0x7fe83b610723 base::MessagePumpDefault::Run()
STDERR: #27 0x7fe83b5fe52f base::MessageLoop::RunHandler()
STDERR: #28 0x7fe83b6957a4 base::RunLoop::Run()
STDERR: #29 0x7fe83b5fd5d4 base::MessageLoop::Run()
STDERR: #30 0x7fe83e3a135c content::RendererMain()
STDERR: #31 0x7fe83e76c856 content::RunZygote()
STDERR: #32 0x7fe83e76cb00 content::RunNamedProcessTypeMain()
STDERR: #33 0x7fe83e76e97d content::ContentMainRunnerImpl::Run()
STDERR: #34 0x7fe83e76bf32 content::ContentMain()
STDERR: #35 0x00000054f79c main
STDERR: #36 0x7fe82c17a76d __libc_start_main
STDERR: #37 0x00000054f685 <unknown>
STDERR: 

For the crash, the unexpected value of 'result' (3) means MOJO_RESULT_INVALID_ARGUMENT.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/02869b24c40dbab8971b6c6fea16040deae8333b

commit 02869b24c40dbab8971b6c6fea16040deae8333b
Author: suzyh <suzyh@chromium.org>
Date: Thu Mar 31 22:42:28 2016

Fix flaky negative-playback-rate animation test.

The animation-state-changes-negative-playback-rate.html layout test
flakily fails due to floating point errors. When setting
animation.startTime to (document.timeline.currentTime + duration),
a floating point difference can sometimes cause this to be set past
the point where the animation would be finished, thus producing
an animation that was not running. This patch prevents this from
happening by setting the startTime halfway through the animation
instead of at the end.

BUG= 593982 

Review URL: https://codereview.chromium.org/1843283003

Cr-Commit-Position: refs/heads/master@{#384422}

[modify] https://crrev.com/02869b24c40dbab8971b6c6fea16040deae8333b/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/02869b24c40dbab8971b6c6fea16040deae8333b/third_party/WebKit/LayoutTests/web-animations-api/animation-state-changes-negative-playback-rate.html

I expect this is now fixed. I'm not looking into the crash in the "WebKit Linux non-Oilpan (dbg)" bot since non-Oilpan stuff is going away. Feel free to reopen this bug if the test continues to flake.

Still failing on (WebKit Win non-Oilpan, for example)
"Asserts failed"
https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Win%20non-Oilpan/builds/1290/

Ah. After implementing the fix above, I was no longer seeing these 'approx equal' errors ("expected 50000 but got 49999.99999999999"), so didn't change the assert_equals to assert_approx_equals, but looks like it's still a problem. I'll fix that now.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/313087501309dddbcc94481ee7ef666472079bee

commit 313087501309dddbcc94481ee7ef666472079bee
Author: suzyh <suzyh@chromium.org>
Date: Thu Apr 07 01:28:21 2016

Use 'approx equals' in negative playback rate test

Due to floating point error, some tests in the web-animations-api/
animation-state-changes-negative-playback-rate.html layout test
flakily fail. This patch changes some asserts from assert_equals
to assert_approx_equals with an epsilon of 0.000001.

BUG= 593982 

Review URL: https://codereview.chromium.org/1861473004

Cr-Commit-Position: refs/heads/master@{#385612}

[modify] https://crrev.com/313087501309dddbcc94481ee7ef666472079bee/third_party/WebKit/LayoutTests/web-animations-api/animation-state-changes-negative-playback-rate.html

Blink>ToolsTest renamed to Blink>Infra