WebView failing to call shouldInterceptRequest for this one page
Reported by
car...@instantbits.com,
Oct 29
|
||||
Issue descriptionTHIS TEMPLATE IS FOR FILING BUGS ON THE ANDROID SYSTEM WEBVIEW. GENERAL WEB BUGS SHOULD BE FILED USING A DIFFERENT TEMPLATE! Device name: Pixel XL Android version:9 WebView version (from system settings -> Apps -> Android System WebView): 69.0.3497.100 Application: Web Video Caster Application version: 4.4 URLs (if applicable): This video https://www.zee5.com/tvshows/details/vanjaga-kaadhal/0-6-tvshow_1112102103/latest which is only accessible from India (you'll need a VPN if not there), loads an m3u8. The m3u8 is at a base path of https://zee5vodnd.akamaized.net/hls/True-HD-1080p and all the segments are there as well. For some reason the shouldInterceptRequest method doesn't get called for loading that resource. I tried several different WebView browsers that also use shouldInterceptRequest to find m3u8 and none of them could it. Steps to reproduce: (1) Load the video. (2) Log every call to shouldInterceptRequest Expected result: M3u8 and ts segments should show up on shouldInterceptRequest Actual result: M3u8 and ts segments do not show up on shouldInterceptRequest
,
Oct 30
I also noticed a lot of the calls they make don't trigger shouldInterceptRequest(), in fact I tried to insert an element with a script to a made up path and even that didn't go through shouldInterceptRequest() I'm guessing that site is doing something to circumvent that? is that something the WebView should allow?
,
Oct 30
There's two reasons why shouldInterceptRequest might not be called for a given network load that are probably relevant here: 1) Videos that are being rendered by the Android platform MediaPlayer don't use chromium's network stack to download the video, and so shouldInterceptRequest won't be called. This should only be used for a small number of less common video formats that aren't supported by Chromium's own video renderer; if this is MPEG-TS I think that might be one of them? Not sure though. 2) Web sites with service workers can route their network fetches through their service worker for caching purposes. Service workers are not associated with a particular instance of WebView (since there is just one global service worker for each site, no matter how many webviews there are), and so the service worker's network requests will *not* invoke any particular WebView's shouldInterceptRequest callback. https://developer.android.com/reference/android/webkit/ServiceWorkerController was introduced in API24 to enable apps to get a callback for network traffic from service workers. Chrome devtools should be able to show you whether the site has a service worker or not, and I think that if the video rendering is going through MediaPlayer you won't see the network traffic for the video in devtools either, so you should be able to check if this is what's causing it.
,
Oct 30
I believe based on Chrome devtools that the 2 situation is what is happening. Is there or will there be a way in the future to intercept these calls?
,
Oct 30
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 31
As I said in the comment, you can use ServiceWorkerController in API24+ (or the support library version in API21+: https://developer.android.com/reference/androidx/webkit/ServiceWorkerControllerCompat )
,
Nov 3
Thank you, guess I missed that part. |
||||
►
Sign in to add a comment |
||||
Comment 1 by jbanavatu@chromium.org
, Oct 30