How do I know if the provided example fails?

video.networkState == 2

video.networkstate is always undefined on my ToT build

Oops, video.networkState is always 1 on my ToT build.

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

commit a89cc8bcb5d204e3f42eb56d2db24837ba0d3a8a
Author: hubbe <hubbe@chromium.org>
Date: Wed Nov 09 04:28:06 2016

media: Make sure we transition back to a non-loading state

An earilier bug-workaround kept the media in a loading state when
a read operation was pending, but didn't always transition back to
idle when the read operation was done. This CL fixes the problem
by making sure that we check the loading state after read callbacks.

These extra calls to check the loading state can in some cases cause
us to miss progress callbacks. We fix this by allowing in-flight
progress callbacks to complete even if reader_ has been destroyed.

BUG= 662615 

Review-Url: https://codereview.chromium.org/2481673004
Cr-Commit-Position: refs/heads/master@{#430860}

[modify] https://crrev.com/a89cc8bcb5d204e3f42eb56d2db24837ba0d3a8a/media/blink/multibuffer_data_source.cc
[modify] https://crrev.com/a89cc8bcb5d204e3f42eb56d2db24837ba0d3a8a/media/blink/multibuffer_data_source_unittest.cc
[modify] https://crrev.com/a89cc8bcb5d204e3f42eb56d2db24837ba0d3a8a/media/blink/multibuffer_reader.cc

This is a leak no, so it should be merged?

Your change meets the bar and is auto-approved for M55 (branch: 2883)

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

commit 726c376476785452c478c4bc928c12c1eb62e35d
Author: Fredrik Hubinette <hubbe@google.com>
Date: Thu Nov 10 18:29:57 2016

media: Make sure we transition back to a non-loading state

An earilier bug-workaround kept the media in a loading state when
a read operation was pending, but didn't always transition back to
idle when the read operation was done. This CL fixes the problem
by making sure that we check the loading state after read callbacks.

These extra calls to check the loading state can in some cases cause
us to miss progress callbacks. We fix this by allowing in-flight
progress callbacks to complete even if reader_ has been destroyed.

BUG= 662615 

Review-Url: https://codereview.chromium.org/2481673004
Cr-Commit-Position: refs/heads/master@{#430860}
(cherry picked from commit a89cc8bcb5d204e3f42eb56d2db24837ba0d3a8a)

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

Cr-Commit-Position: refs/branch-heads/2883@{#521}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[modify] https://crrev.com/726c376476785452c478c4bc928c12c1eb62e35d/media/blink/multibuffer_data_source.cc
[modify] https://crrev.com/726c376476785452c478c4bc928c12c1eb62e35d/media/blink/multibuffer_data_source_unittest.cc
[modify] https://crrev.com/726c376476785452c478c4bc928c12c1eb62e35d/media/blink/multibuffer_reader.cc

Tested the issue on windows 7 using chrome version 55.0.2883.52 with the below steps

1.Opened the video-leak.html
2.Clicked on Again
3.Move the mouse on the image
4.Not observed any user gesture along with the mouse.

Please find the attached screen cast and provide us steps to verify the fix from test team end.

Note::Getting the blank for the video-leak.html on both Linux and MacOS.

Thanks,

Deleted: 662615.mp4 507 KB

	662615.mp4 507 KB View Download

In order to verify this bug you actually have to put video-leak.html and small.mp4 into a directory served by an HTTP server that doesn't support ranges.
One way to do so is to run "python -m SimpleHTTPServer 8000" in a directory containing those files.

Then (after loading video-leak.html) you have to open up the dev console and type "video.networkState". If the result is 2, the test has failed.

Thank you hubbe@, Verified the fix by following steps provided in comment#12 on Windows 7,10, Mac and Linux with Chrome Version 55.0.2883.52.