"error" event not triggered when a 404 followed a 302 response on a video tag
Reported by
baiy...@gmail.com,
Oct 4 2016
|
|||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0 Steps to reproduce the problem: 1.Create a video tag e.g.: <video src="https://a.com/GetVideo" ...></video> 2.Let the src url ("https://a.com/GetVideo") return a 302 response, e.g.: "https://b.com/foo.mp4" 3.Let the redirect url ("https://b.com/foo.mp4") return a 404 response. What is the expected behavior? The "error" event or "onerror" callback triggered. What went wrong? Older verions (at least ver 33 and ver 51) for chrome, IE, Firefox and Safari all trigger the event correctly, But the newest chrome don't. Did this work before? N/A Chrome version: 53.0.2785.143 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: 23.0.0.162
,
Oct 4 2016
Could you please set up a server that we can test this with? Our test team needs some way to find the change that is causing this issue.
,
Oct 4 2016
You can test it using this page: https://zhiyejing.com/DRes/Plugin/BMOD - Topic/fend/pages/detailtopicvideo.html?vid=95612160180231922 But we plan to remove this page in few days, please test it quickly.
,
Oct 5 2016
Unable to reproduce the issue in Windows 10-Chrome stable version-53.0.2785.143 & 51.0.2704.79 with the below steps: 1. Opened new chrome browser 2. Press Function key+F12 3. Open URL "https://zhiyejing.com/DRes/Plugin/BMOD%20-%20Topic/fend/pages/detailtopicvideo.html?vid=95612160180231922" 4. Observed "401 error" Please find the attached screencasts of Latest (53), 51 versions and please let us know if anything missed to reproduce the issue. 4.
,
Oct 5 2016
401 is ok, because you are anonymous, please ignore it. And as I have been said, older version include version 51 and version 33's behavior is correctly. As well as all other browsers like IE, Firefox and Safari. So 652737-Win 51 version.mp4's behavior is right. I can only reproduce is bug on chrome version 53.0.2785.143. In bad.wmv, 404 not triggered a "error" event, so the java script could not handle it. In right.wmv, java script caught the event correctly, so we can try another "GetVideo" (which cause another 302 and 404 too). Using the "error" handler, we iterate through multiple resolutions, e.g.: from 720p, 480p, 360p to 180p. If the "error" event not triggered, than we freezed on the first request and could never try another resolution.
,
Oct 5 2016
PS: you 652737-win stable 143.mp4 already reproduced the problem exactly: the last line is a get error (I guess it's a 404), and this error not fired as the video tag's "error" event.
,
Oct 10 2016
I think this onError event of <video> tag should go to blink team. Please feel free to add Internals>media>video back if need.
,
Oct 11 2016
,
Oct 11 2016
+Fredrik in case there were some changes to fetching media that could've caused this in M53. Seems like the bug has been confirmed.
,
Oct 18 2016
Seems a multibuffer issue if it started in m51.
,
Oct 27 2016
Created a new test page which demonstrates the problem: http://fredrik.hubbe.net/test17.html Should say "ERROR", but doesn't.
,
Oct 28 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e547f4e0b3e0796fb44b508d20ea313f3cb735f1 commit e547f4e0b3e0796fb44b508d20ea313f3cb735f1 Author: hubbe <hubbe@chromium.org> Date: Fri Oct 28 02:21:10 2016 Media: fail properly on 404 after redirect Because the readers were still hooked up to the pre-redirect URL, calling Fail() did not propagate properly. Also fix some debug statements I needed to find the problem. BUG= 652737 Review-Url: https://codereview.chromium.org/2455693004 Cr-Commit-Position: refs/heads/master@{#428251} [modify] https://crrev.com/e547f4e0b3e0796fb44b508d20ea313f3cb735f1/media/blink/multibuffer_data_source_unittest.cc [modify] https://crrev.com/e547f4e0b3e0796fb44b508d20ea313f3cb735f1/media/blink/resource_multibuffer_data_provider.cc
,
Oct 28 2016
,
Oct 28 2016
Worth merging? |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by cbiesin...@chromium.org
, Oct 4 2016