Make the logic for stream interception by MimeHandlerViews consistent with starting the plugin
Currently there is logic in the renderer which checks whether a plugin can handle a mime type and if it can the plugin is started. This is also how MimeHandlerView plugins are started in the renderer. MimeHandlerViews also rely on the original http request being intercepted as a stream which the plugin can read when it chooses. This happens in the browser. Currently the logic for determining whether the stream should be intercepted is different to the logic for determining whether to start the plugin which can lead to problems in some cases. This CL makes sure the logic is the same: on both sides we check whether the plugin can handle the mime type. MimeHandlerView plugins load a chrome extension inside a BrowserPlugin. Once it has been determined that the plugin can handle the mime type inside BufferedResourceHandler, the extension ID of the plugin is passed down through into ChromeResourceDispatcherHostDelegate::ShouldInterceptResourceAsStream. It is then checked that the extension is enabled and if so the stream is intercepted. There is some complexity because we also need to support the legacy case where the stream is intercepted for the streamsPrivate api in which case there is no MimeHandlerView plugin. This CL was originally written by deepak.m1@samsung.com (Deepak Mittal) and landed here: https://codereview.chromium.org/953793003/. It was reverted because of a bug it triggered with not downloading PDFs when the PDF plugin was disabled. This bug has been addressed and a test added for that case. BUG=443466 Review URL: https://codereview.chromium.org/1164073006 Cr-Commit-Position: refs/heads/master@{#339816}
Showing
Please register or sign in to comment