Bug 33686

Summary: Media elements' networkState is left at NETWORK_LOADING if resource load delegate returns null from willSendRequest
Product: WebKit Reporter: Adam Roben (:aroben) <aroben>
Component: MediaAssignee: Eric Carlson <eric.carlson>
Status: NEW    
Severity: Normal CC: ahmad.saleem792, andersca, destra, eric.carlson, jer.noble
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Attachments:
Description Flags
patch with test case none

Adam Roben (:aroben)
Reported 2010-01-14 13:34:42 PST
Created attachment 46603 [details] patch with test case To reproduce: 1. Apply the attached test case patch 2. run-webkit-tests media The test shows that when the resource load delegate blocks the load of a media element by returning null from willSendRequest, the media element's networkState is left at NETWORK_LOADING. (The media element's m_delayingTheLoadEvent flag also remains true, but that has no effect because the flag is only checked in an assertion. (!)) Changing networkState to NETWORK_NO_SOURCE would make a lot more sense, I think. (So would setting m_delayingTheLoadEvent to false.)
Attachments
patch with test case (2.18 KB, patch)
2010-01-14 13:34 PST, Adam Roben (:aroben) 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Adam Roben (:aroben)
Comment 1 2010-01-14 13:38:17 PST
<rdar://problem/7543218>
Adam Roben (:aroben)
Comment 2 2010-01-19 13:07:33 PST
Eric Carlson and I talked a little about what the desired behavior here is. We discussed having the media element pretend that @src or a given <source> element doesn't exist if its load is blocked by the resource load delegate. But that leads to strange, clearly-non-standard behavior in cases like <video src=blocked.mp4><source src=notblocked.mp4></video>. (If we pretended that @src wasn't there because the resource load delegate blocked it, we'd proceed to try to load the <source> element. But the spec clearly states that @src and <source> should be mutually exclusive.) We also discussed treating blocked loads the same as 404s. But then we talked about how <iframe>, <object>/<embed>, and <img> don't broadcast any error events when their loads are blocked by the resource load delegate. They basically behave as if they were told to load about:blank. Treating blocked loads like 404s would lead to firing error events for media elements, which would not follow the precedent set by the other elements above. So we could try to do something similar for media elements. But what would that mean exactly?
Adam Roben (:aroben)
Comment 3 2010-01-20 14:29:50 PST
Another data point: <object> does not render fallback content when its load is blocked via willSendRequest.
Adam Roben (:aroben)
Comment 4 2010-01-22 07:21:20 PST
Eric and I discussed a proposal yesterday that I think is quite similar to our behavior for <iframe>, <img>, <object>, etc.: 1) For <video> with a blocked @src, video.load() is a no-op 2) For <video> with one or more blocked <source> and no unblocked <source>, video.load() is a no-op 3) For <video> with one or more blocked <source> and one or more unblocked <source>, video.load() pretends as if the blocked <source> didn't exist (<video src=blocked.mp4><source src=notblocked.mp4></video> behaves as in (1).) Eric thinks this should be pretty easy to implement.
Ahmad Saleem
Comment 5 2023-10-15 06:34:24 PDT
We don't have this test case in our repository. @Eric & @Jer - is this still applicable?
Ahmad Saleem
Comment 6 2024-02-22 17:04:01 PST
``` <!DOCTYPE html> <html> <head> <title></title> <script src=video-test.js></script> </head> <body> <audio src="content/test.wav"></audio> <video src="content/test.mp4"></video> <script> if (window.testRunner) { testRunner.dumpAsText(); testRunner.setWillSendRequestReturnsNull(true); } var audio = document.getElementsByTagName("audio")[0]; run("audio.load()"); testExpected("audio.networkState", "HTMLMediaElement.prototype.NETWORK_NO_SOURCE", "=="); var video = document.getElementsByTagName("video")[0]; run("video.load()"); testExpected("video.networkState", "HTMLMediaElement.prototype.NETWORK_NO_SOURCE", "=="); endTest(); </script> </body> </html> ``` Just updated test to use `testRunner`. ___ On WebKit ToT (with some media related fixes - we fail this): ___ RUN(audio.load()) EXPECTED (audio.networkState == 'HTMLMediaElement.prototype.NETWORK_NO_SOURCE'), OBSERVED '3' FAIL RUN(video.load()) EXPECTED (video.networkState == 'HTMLMediaElement.prototype.NETWORK_NO_SOURCE'), OBSERVED '3' FAIL END OF TEST ____
Eric Carlson
Comment 7 2024-02-23 10:03:23 PST
EXPECTED (audio.networkState == 'HTMLMediaElement.prototype.NETWORK_NO_SOURCE'), OBSERVED '3' FAIL `HTMLMediaElement.prototype.NETWORK_NO_SOURCE` is 3.
Eric Carlson
Comment 8 2024-02-23 10:04:51 PST
The problem is the quotes around `HTMLMediaElement.prototype.NETWORK_NO_SOURCE`, the expected value is not eval()'d
Note You need to log in before you can comment on or make changes to this bug.