Issue metadata
Sign in to add a comment
|
Android webview cannot intercept custom scheme resource requests with WebViewClient shouldInterceptRequest
Reported by
edba...@blackberry.com,
Jun 20 2017
|
||||||||||||||||||||||||
Issue descriptionSteps to reproduce the problem: 1. Override shouldInterceptRequest() method in WebViewClient 2. Make a resource request with a custom scheme like an image 3. shouldInterceptRequest() is never invoked What is the expected behavior? The method shouldInterceptRequest() should be invoked for the requested resource What went wrong? Expected method is not invoked Did this work before? Yes 59.0.3071 Does this work in other browsers? N/A Chrome version: 60.0.3112.20 Channel: stable OS Version: 6.0.1 Flash Version: Appears to be a regression in Chrome beta 60.0.3112.20. Reduced test case apk and source code attached.
,
Jul 13 2017
what's the test app supposed to do?
,
Jul 13 2017
The test app should show an image in the webview that's loaded by using shouldInterceptRequest() to return a response in the webviewclient
,
Jul 13 2017
I think on m60, it's treating "cid:world.jpg" as a relative url, rather than a protocol. And ends up being file:///android_asset/cid:world.jpg, which of course doesn't exist. And android_asset urls are special and I'm not sure if they can be intercepted at all.
,
Jul 13 2017
Hm, if that's the case this is pretty badly broken then. :(
,
Jul 13 2017
,
Jul 13 2017
Doesn't gmail also use cid: as a scheme? Or does it use it as a hierarchical URL cid:// ?
,
Jul 13 2017
bisected to https://codereview.chromium.org/2834013002, but author is on vacation right now I can't see any change to url parsing in that CL though..
,
Jul 13 2017
From the design doc linked from the CL: """ What if the url is not found in the archive? Without PlzNavigate, the request is aborted in this case. We should do the same here. MHTML Archives can serve resources for almost any URLs, but the one with the Content-Id “cid:” protocol can only be handled by an MHTML Archives. So when there is no archive but the url have the “cid” protocol, then the request must be aborted as well. """
,
Jul 13 2017
Aha, you've reminded me that I've seen this before. This is a dupe then, and there's a fix uploaded already..
,
Jul 13 2017
Yeah, so it's not a url parsing issue. It's just cid: protocol is blocked outside of mhtml archives now. https://codereview.chromium.org/2834013002/diff/240001/third_party/WebKit/Source/platform/loader/fetch/ResourceFetcher.cpp#newcode600 The fix relaxes the check for subresources. It's uploaded, but uhh, author is on vacation for a few more days... |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by boliu@chromium.org
, Jul 13 2017