PDF is not shown when service worker provides the response with ServiceWorkerServicification
Reported by
rick.lub...@cofano.nl,
Dec 19
|
||||||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:64.0) Gecko/20100101 Firefox/64.0 Steps to reproduce the problem: 1. I can't seem to upload zip files, so please clone my Git repository: https://github.com/goldenice/chrome-serviceworker-issue-replication 2. Install node dependencies with `npm install` or `yarn install --pure-lockfile` 3. Run `yarn start` 4. Go to localhost:1337 (this installs the service worker) 5. Click the Download PDF link, this will fail to display properly, and if the result of the request is saved manually you'll see extra bytes are included in the file for every byte greater than 7F, indicating an encoding issue. 6. Remove service worker from console and go to the same URI (http://localhost:1337/target.pdf) to confirm it now downloads as expected. What is the expected behavior? Fetch called from the serviceworker and event.respondWith() called with the raw result yields the same or very comparable result as not calling event.respondWith() in the first place. It should explicitly not parse this with any encoding as it is a binary file. What went wrong? The file is downloaded and parsed in the step between the download in the service worker and parsing by the browser itself (that is my suspicion). It does not handle a blob well. Did this work before? Yes 70.0.3538.110 Does this work in other browsers? Yes Chrome version: 71.0.3578.98 Channel: stable OS Version: 10 Flash Version: I have reproduced this in Windows 10, Ubuntu 16.04, on Chrome 71 and 73. Chrome 70 on Ubuntu 16.04 is still okay.
,
Dec 19
Will try to get to this tomorrow.
,
Dec 20
shimazu: I'm guessing this is caused by ServiceWorkerServicification and could be about MIME sniffing/downloads. If you have a chance can you take a look? I'm working on https://crbug.com/916070 now.
,
Dec 20
Sure. I can investigate this today but the fix will be next week.
,
Dec 20
I could see that pdf isn't shown on navigation, but download worked properly. What was the step of "the request is saved manually"? I tried a few but all were the same (good pdf): Ctrl-S on http://localhost:1337/target.pdf, right-click on "Download PDF" link and selecting "Save as...", and "Save as HAR with content" in DevTools.
,
Dec 20
,
Dec 20
Yes, download works since the serviceworker only kicks in on a navigation request. I should have clarified: I meant opening the broken request in the network inspector and Right Click->Save As the response.
,
Dec 20
Hmm, I tried ToT with dcheck_always_on=true, ExtensionsGuestViewMessageFilter::CreateMimeHandlerViewGuestOnUIThread() always crashes with the following stack trace. I tried to print |view_id|, it looked the body of pdf. It seems something wrong... It worked with a flag "--disabled-features=ServiceWorkerServicification,NetworkService", so this seems affected by S13nSW. == [130954:130954:1220/155614.425778:FATAL:values.cc(151)] Check failed: IsStringUTF8(string_value_). #0 0x7fe990b271ff base::debug::StackTrace::StackTrace() #1 0x7fe990a49fea logging::LogMessage::~LogMessage() #2 0x7fe990b196a7 base::Value::Value() #3 0x7fe990b1d58c base::DictionaryValue::SetString() #4 0x55c1b98c2a99 extensions::ExtensionsGuestViewMessageFilter::CreateMimeHandlerViewGuestOnUIThread() #5 0x55c1b98c4b98 _ZN4base8internal13FunctorTraitsIMN10extensions32ExtensionsGuestViewMessageFilterEFviRKNSt3__112basic_stringIcNS4_11char_traitsIcEENS4_9allocatorIcEEEEiRKN3gfx4SizeEN4mojo16InterfacePtrInfoINS2_12mime_handler19BeforeUnloadControlEEEibEvE6InvokeISN_13scoped_refptrIS3_EJiSA_iSE_SL_ibEEEvT_OT0_DpOT1_ #6 0x55c1b98c4a9d _ZN4base8internal7InvokerINS0_9BindStateIMN10extensions32ExtensionsGuestViewMessageFilterEFviRKNSt3__112basic_stringIcNS5_11char_traitsIcEENS5_9allocatorIcEEEEiRKN3gfx4SizeEN4mojo16InterfacePtrInfoINS3_12mime_handler19BeforeUnloadControlEEEibEJ13scoped_refptrIS4_EiSB_iSF_SM_ibEEEFvvEE7RunOnceEPNS0_13BindStateBaseE #7 0x7fe990a2bb09 base::debug::TaskAnnotator::RunTask() #8 0x7fe990a592b0 base::MessageLoopImpl::RunTask() #9 0x7fe990a59a62 base::MessageLoopImpl::DoWork() #10 0x7fe990a5c46f base::(anonymous namespace)::WorkSourceDispatch() #11 0x7fe9839a9fc7 g_main_context_dispatch #12 0x7fe9839aa200 <unknown> #13 0x7fe9839aa28c g_main_context_iteration #14 0x7fe990a5c1a2 base::MessagePumpGlib::Run() #15 0x7fe990a58d85 base::MessageLoopImpl::Run() #16 0x7fe990a8c096 base::RunLoop::Run() #17 0x55c1b9f2cdc8 ChromeBrowserMainParts::MainMessageLoopRun() #18 0x7fe98dcf6f04 content::BrowserMainLoop::RunMainMessageLoopParts() #19 0x7fe98dcf9b83 content::BrowserMainRunnerImpl::Run() #20 0x7fe98dcf38ba content::BrowserMain() #21 0x7fe98e851c18 content::ContentMainRunnerImpl::RunServiceManager() #22 0x7fe98e8517e3 content::ContentMainRunnerImpl::Run() #23 0x7fe97fc1e530 service_manager::Main() #24 0x7fe98e84f9f1 content::ContentMain() #25 0x55c1b96f51b3 ChromeMain #26 0x7fe9820982b1 __libc_start_main #27 0x55c1b96f502a _start
,
Dec 21
,
Dec 21
,
Dec 25
This looks happening only when S13nSW is on and NetworkService is off. I'm now suspecting that the plugin for PDF Viewer works wrongly when service worker returns the response to the renderer process without interference by ResourceDispatcherHost. PDF is successfully loaded when ServiceWorker returns from the fetch event without calling respondWith() probably because the request goes to the ResourceDispatcherHost and it handles the plugin.
,
Dec 25
Updated the title. I guess this is only related to PDF. This happens when 1: ServiceWorkerServicification is on, NetworkService is off. 2: A PDF response is served by a service worker. 3: The PDF cannot be shown in the PDF plugin. PDF plugin seems overriding the response body to send view_id from the browser process (? still not sure), but S13nSW doesn't work well since the response is provided through the service worker directly to the renderer process. I need to dig into a bit more around how PDF plugin overrides the response body.
,
Dec 25
https://cs.chromium.org/chromium/src/chrome/renderer/url_loader_throttle_provider_impl.cc?g=0&l=234 This code looks creating special throttle when NetworkService is enabled. ServiceWorker might need to do similar thing when the pdf is provided from the service worker.
,
Dec 25
Tried to create a PluginResponseInterceptor when S13nSW is on, view_id gets correct. https://cs.chromium.org/chromium/src/chrome/browser/chrome_content_browser_client.cc?type=cs&sq=package:chromium&g=0&l=4517 But it's still not working. "Failed to load PDF document." is shown. Needs more investigation.
,
Dec 29
Adding some findings: - The repro can be simplified to putting index.html, serviceworker.js, target.pdf in a directory and running `python -m SimpleHTTPServer 9898` and navigating to localhost:9898. - Confirmed that |view_id| causes DCHECK failures on builds with that enabled. Running with DCHECK off won't crash the browser but brings up an empty PDF viewer. - Confirmed that setting |network_service_enabled| = true in ChromeContentBrowserClient::CreateURLLoaderThrottles seems to fix the DCHECK. But we get "Failed to load PDF document". That error is shown even with the service worker unregistered.
,
Dec 30
Having the same problem when using the fetch event and the response is a PDF. Attached is a very simple service worker and a PDF file to duplicate the issue Using the developers Developers Tools, when I check "Bypass for network" under the service worker, the PDF loads correctly. When I un-check it, I get a gray screen. Also, this warring always comes when the service worker is running when fetching PDFs "Resource interpreted as Document but transferred with MIME type application/pdf" Chrome version: 71.0.3578.98 Windows 10 Other browser do not have this issue
,
Jan 1
Let me put what I've done before going on my vacation. 1: The error is shown by calling OutOfProcessInstance::DocumentLoadFailed() at OutOfProcessInstance::DidOpen(). Probably it fails to load the pdf. 2: I've tried to look around the code to understand how PDF is working. At first, it loads the document "http://localhost:1733/target.pdf". PluginResponseInterceptor intercepts the URLLoader/URLLoaderClient. On the renderer process, PluginDocument is created since the mime type is pdf. At that time, BrowserPlugin is created and it eventually passes the view_id to MimeHandlerViewContainer (= BrowserPluginDelegate). MimeHandlerViewContainer sends some IPC to the browser process, and the browser process creates another WebContents. It'll be an URL of the PDF viewer extension. In the second navigation triggered by making WebContents, the extension is loaded with "subresource_overrides" in the URLLoaderBundle which is passed on RenderFrameImpl::CommitNavigation. The subresource_overrides contains the URLLoader/URLLoaderClient connected to the service worker. The PDF viewer extension loads "chrome-extensions://mhjfbmdgcfjbbpaeojofohoefgiehjai/VIEW_ID", and it should be the original PDF. 3: I've suspected that the lifetime of ServiceWorkerNavigationLoader was wrong, but probably it's actually correct (the loader isn't destructed until the URLLoaderPtr is alive"). So I'm still not sure what's wrong. I'm guessing that there might be some other NetworkService-only switches.
,
Jan 5
,
Jan 5
,
Jan 7
Thanks shimazu@. I investigated more based on your notes. More findings: - content::PepperURLLoaderHost::DidFail() is called with net::ERR_FILE_NOT_FOUND. - We get to DidFail from ThrottlingURLLoader::OnComplete() -> content::URLLoaderClientImpl::OnComplete() -> content::ResourceDispatcher::OnRequestComplete() -> ... -> blink::ResourceLoader::DidFail() -> ... -> blink::Resource::FinishAsError() -> ... -> blink::ThreadableLoader::NotifyFinished() -> ... -> blink::WebAssociatedURLLoaderImpl::ClientAdapter::DidFail() - The failed URL has the shape "chrome-extension://mhjfbmdgcfjbbpaeojofohoefgiehjai/38762f12-b905-4412-aa35-79d50cd64421". - The failure comes from net::URLRequestFileJob::DidFetchMetaInfo. The file path passed to net::URLRequestFileJob is empty. - When NetworkService is on (the bug doesn't happen), we don't use net::URLRequestFileJob at all. - When ServiceWorkerServification is off (the bug doesn't happen), we also don't use net::URLRequestFileJob. The URL loaded at OutOfProcessInstance::LoadUrl() has the shape "blob:chrome-extension://mhjfbmdgcfjbbpaeojofohoefgiehjai/0b5e8ef0-ee3a-4dbe-9ae2-57e8872ac120". Note the "blob:" here which doesn't show up for NetworkService. So looks like we need ServiceWorkerServification to act more like the non-servicified path and load a blob, or act more like the NetworkService path and don't use net::URLRequestFileJob.
,
Jan 7
The ERR_FILE_NOT_FOUND gets to the url loader client via: network::mojom::URLLoaderClientProxy::OnComplete() content::MojoAsyncResourceHandler::OnResponseCompleted() content::InterceptingResourceHandler::OnResponseCompleted() content::LayeredResourceHandler::OnResponseCompleted() content::CrossSiteDocumentResourceHandler::OnResponseCompleted() content::MimeSniffingResourceHandler::OnResponseCompleted() content::LayeredResourceHandler::OnResponseCompleted() content::ResourceLoader::ResponseCompleted() content::ResourceLoader::OnResponseStarted() net::URLRequest::NotifyResponseStarted() net::URLRequestJob::NotifyStartError() net::URLRequestFileJob::DidFetchMetaInfo()
,
Jan 7
There's a nice writeup of how this works for NetworkService at https://docs.google.com/document/d/1FUuS7fmpTmpaBiT4wgXBPpeFUP9nRBpRouSF5qsdv5I/edit# from the CL https://chromium-review.googlesource.com/920142. Still not 100% clear to me how this is breaking with ServiceWorkerServicification.
,
Jan 7
I see. The browser is sending |subresource_overrides| in CommitNavigation but the renderer ignores it when NetworkService is off because |subresource_loader_factories| is null.
,
Jan 7
,
Jan 7
Re "So looks like we need ServiceWorkerServification to act more like the non-servicified path and load a blob, or act more like the NetworkService path and don't use net::URLRequestFileJob." note that there isn't actually any blob loading going on in either case. In both cases this is loading a "stream" (from content/browser/streams/), just in the pre-network-service case this stream loading is hacked on top of blob URLs, while post-network-service this is more directly loaded. This is also the reason that blob URL mojofication hasn't been turned on yet even though it's "finished", these old hacks on top of blob URLs don't work with blob URL mojofication.
,
Jan 7
This issue is marked as a release blocker with no milestone associated. Please add an appropriate milestone. All release blocking issues should have milestones associated to it, so that the issue can tracked and the fixes can be pushed promptly. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 7
Reminder M72 Stable is coming VERY soon. Please review this bug and assess if this is indeed a RBS. If not, please remove the RBS label. If so, please make sure to land the fix and request a merge into the release branch ASAP. Thank you.
,
Jan 7
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/032206b324780bb640eb7bc8c6d073f84d4c8692 commit 032206b324780bb640eb7bc8c6d073f84d4c8692 Author: Matt Falkenhagen <falken@chromium.org> Date: Mon Jan 07 22:29:14 2019 service worker: Fix PDF loads when servicification is enabled. When ServiceWorkerServicification was enabled while NetworkService was disabled, navigations to PDFs were failing because PluginResponseInterceptorURLLoaderThrottle wasn't created. This response interceptor is needed when the request goes through the network service/request interceptor path as described in https://chromium-review.googlesource.com/c/chromium/src/+/920142/. When ServiceWorkerServicification is disabled, or a service worker doesn't handle the request, the throttle isn't needed since loading the PDF goes through the legacy ResourceDispatcherHost path. Tests for navigations to PDF are added. I didn't add tests for <embed> or <object> loading PDFs since these already skip service workers ( https://crbug.com/771933 ) and verified manually these embeds work. Bug: 916514 Change-Id: I250503b85de4a92ec94f69ae41ddb2c4af1fb065 Reviewed-on: https://chromium-review.googlesource.com/c/1395872 Reviewed-by: John Abd-El-Malek <jam@chromium.org> Commit-Queue: Matt Falkenhagen <falken@chromium.org> Cr-Commit-Position: refs/heads/master@{#620503} [modify] https://crrev.com/032206b324780bb640eb7bc8c6d073f84d4c8692/chrome/browser/chrome_content_browser_client.cc [modify] https://crrev.com/032206b324780bb640eb7bc8c6d073f84d4c8692/chrome/browser/pdf/pdf_extension_test.cc [modify] https://crrev.com/032206b324780bb640eb7bc8c6d073f84d4c8692/chrome/browser/plugins/plugin_response_interceptor_url_loader_throttle.cc [modify] https://crrev.com/032206b324780bb640eb7bc8c6d073f84d4c8692/chrome/test/data/service_worker/create_service_worker.html [add] https://crrev.com/032206b324780bb640eb7bc8c6d073f84d4c8692/chrome/test/data/service_worker/empty.js [add] https://crrev.com/032206b324780bb640eb7bc8c6d073f84d4c8692/chrome/test/data/service_worker/empty.js.mock-http-headers [add] https://crrev.com/032206b324780bb640eb7bc8c6d073f84d4c8692/chrome/test/data/service_worker/network_fallback_worker.js [add] https://crrev.com/032206b324780bb640eb7bc8c6d073f84d4c8692/chrome/test/data/service_worker/network_fallback_worker.js.mock-http-headers [add] https://crrev.com/032206b324780bb640eb7bc8c6d073f84d4c8692/chrome/test/data/service_worker/respond_with_fetch_worker.js [add] https://crrev.com/032206b324780bb640eb7bc8c6d073f84d4c8692/chrome/test/data/service_worker/respond_with_fetch_worker.js.mock-http-headers [modify] https://crrev.com/032206b324780bb640eb7bc8c6d073f84d4c8692/content/renderer/loader/child_url_loader_factory_bundle.cc [modify] https://crrev.com/032206b324780bb640eb7bc8c6d073f84d4c8692/content/renderer/loader/child_url_loader_factory_bundle.h [modify] https://crrev.com/032206b324780bb640eb7bc8c6d073f84d4c8692/content/renderer/loader/tracked_child_url_loader_factory_bundle.cc [modify] https://crrev.com/032206b324780bb640eb7bc8c6d073f84d4c8692/content/renderer/render_frame_impl.cc [modify] https://crrev.com/032206b324780bb640eb7bc8c6d073f84d4c8692/content/renderer/renderer_webapplicationcachehost_impl.cc [modify] https://crrev.com/032206b324780bb640eb7bc8c6d073f84d4c8692/content/renderer/service_worker/service_worker_context_client.cc [modify] https://crrev.com/032206b324780bb640eb7bc8c6d073f84d4c8692/content/renderer/shared_worker/embedded_shared_worker_stub.cc
,
Jan 8
How is the change listed at #28 looking in canary? Is it important and safe to merge to M72 this late in release cycle?
,
Jan 8
This is a serious regression that was only discovered after ServiceWorkerServicification went to 100% on Stable in 71. I want to merge to 72. I'll request merge after verifying in Canary.
,
Jan 9
Requesting merge per c#30. The fix is in canary 73.0.3665.0. Verified the fix works in canary. The crash dashboard looks fine[1][2]. [1] https://crash.corp.google.com/browse?q=product_name%3D%27Chrome%27+AND+expanded_custom_data.ChromeCrashProto.channel%3D%27canary%27+AND+expanded_custom_data.ChromeCrashProto.ptype%3D%27renderer%27+and+product.version+>%3D+%2773.0.3664.3%27&compProp=product.Version&v1=73.0.3664.3&v2=73.0.3665.0 [2] https://crash.corp.google.com/browse?q=product_name%3D%27Chrome%27+AND+expanded_custom_data.ChromeCrashProto.channel%3D%27canary%27+AND+expanded_custom_data.ChromeCrashProto.ptype%3D%27browser%27+and+product.version+>%3D+%2773.0.3664.3%27&compProp=product.Version&v1=73.0.3664.3&v2=73.0.3665.0#magicsignature:40,-magicsignature2:30,-stablesignature:30
,
Jan 9
This bug requires manual review: M72 has already been promoted to the beta branch, so this requires manual review Please contact the milestone owner if you have questions. Owners: govind@(Android), kariahda@(iOS), djmm@(ChromeOS), abdulsyed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 9
Approving merge to M72 branch 3626 based on comments #30 and #31. Please merge ASAP and mark bug as fixed after the merge. Thank you.
,
Jan 9
Building a merge patch since there is a minor conflict due to refactoring.
,
Jan 9
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3b3f051f0a09aa75f5a0d85cb9d2697909005608 commit 3b3f051f0a09aa75f5a0d85cb9d2697909005608 Author: Matt Falkenhagen <falken@chromium.org> Date: Wed Jan 09 00:47:59 2019 M72: service worker: Fix PDF loads when servicification is enabled. When ServiceWorkerServicification was enabled while NetworkService was disabled, navigations to PDFs were failing because PluginResponseInterceptorURLLoaderThrottle wasn't created. This response interceptor is needed when the request goes through the network service/request interceptor path as described in https://chromium-review.googlesource.com/c/chromium/src/+/920142/. When ServiceWorkerServicification is disabled, or a service worker doesn't handle the request, the throttle isn't needed since loading the PDF goes through the legacy ResourceDispatcherHost path. Tests for navigations to PDF are added. I didn't add tests for <embed> or <object> loading PDFs since these already skip service workers ( https://crbug.com/771933 ) and verified manually these embeds work. (cherry picked from commit 032206b324780bb640eb7bc8c6d073f84d4c8692) Bug: 916514 Change-Id: I250503b85de4a92ec94f69ae41ddb2c4af1fb065 Reviewed-on: https://chromium-review.googlesource.com/c/1395872 Reviewed-by: John Abd-El-Malek <jam@chromium.org> Commit-Queue: Matt Falkenhagen <falken@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#620503} Reviewed-on: https://chromium-review.googlesource.com/c/1401822 Reviewed-by: Matt Falkenhagen <falken@chromium.org> Cr-Commit-Position: refs/branch-heads/3626@{#619} Cr-Branched-From: d897fb137fbaaa9355c0c93124cc048824eb1e65-refs/heads/master@{#612437} [modify] https://crrev.com/3b3f051f0a09aa75f5a0d85cb9d2697909005608/chrome/browser/chrome_content_browser_client.cc [modify] https://crrev.com/3b3f051f0a09aa75f5a0d85cb9d2697909005608/chrome/browser/pdf/pdf_extension_test.cc [modify] https://crrev.com/3b3f051f0a09aa75f5a0d85cb9d2697909005608/chrome/browser/plugins/plugin_response_interceptor_url_loader_throttle.cc [modify] https://crrev.com/3b3f051f0a09aa75f5a0d85cb9d2697909005608/chrome/test/data/service_worker/create_service_worker.html [add] https://crrev.com/3b3f051f0a09aa75f5a0d85cb9d2697909005608/chrome/test/data/service_worker/empty.js [add] https://crrev.com/3b3f051f0a09aa75f5a0d85cb9d2697909005608/chrome/test/data/service_worker/empty.js.mock-http-headers [add] https://crrev.com/3b3f051f0a09aa75f5a0d85cb9d2697909005608/chrome/test/data/service_worker/network_fallback_worker.js [add] https://crrev.com/3b3f051f0a09aa75f5a0d85cb9d2697909005608/chrome/test/data/service_worker/network_fallback_worker.js.mock-http-headers [add] https://crrev.com/3b3f051f0a09aa75f5a0d85cb9d2697909005608/chrome/test/data/service_worker/respond_with_fetch_worker.js [add] https://crrev.com/3b3f051f0a09aa75f5a0d85cb9d2697909005608/chrome/test/data/service_worker/respond_with_fetch_worker.js.mock-http-headers [modify] https://crrev.com/3b3f051f0a09aa75f5a0d85cb9d2697909005608/content/renderer/loader/child_url_loader_factory_bundle.cc [modify] https://crrev.com/3b3f051f0a09aa75f5a0d85cb9d2697909005608/content/renderer/loader/child_url_loader_factory_bundle.h [modify] https://crrev.com/3b3f051f0a09aa75f5a0d85cb9d2697909005608/content/renderer/loader/tracked_child_url_loader_factory_bundle.cc [modify] https://crrev.com/3b3f051f0a09aa75f5a0d85cb9d2697909005608/content/renderer/render_frame_impl.cc [modify] https://crrev.com/3b3f051f0a09aa75f5a0d85cb9d2697909005608/content/renderer/service_worker/service_worker_context_client.cc [modify] https://crrev.com/3b3f051f0a09aa75f5a0d85cb9d2697909005608/content/renderer/shared_worker/embedded_shared_worker_stub.cc
,
Jan 9
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3b3f051f0a09aa75f5a0d85cb9d2697909005608 Commit: 3b3f051f0a09aa75f5a0d85cb9d2697909005608 Author: falken@chromium.org Commiter: falken@chromium.org Date: 2019-01-09 00:47:59 +0000 UTC M72: service worker: Fix PDF loads when servicification is enabled. When ServiceWorkerServicification was enabled while NetworkService was disabled, navigations to PDFs were failing because PluginResponseInterceptorURLLoaderThrottle wasn't created. This response interceptor is needed when the request goes through the network service/request interceptor path as described in https://chromium-review.googlesource.com/c/chromium/src/+/920142/. When ServiceWorkerServicification is disabled, or a service worker doesn't handle the request, the throttle isn't needed since loading the PDF goes through the legacy ResourceDispatcherHost path. Tests for navigations to PDF are added. I didn't add tests for <embed> or <object> loading PDFs since these already skip service workers ( https://crbug.com/771933 ) and verified manually these embeds work. (cherry picked from commit 032206b324780bb640eb7bc8c6d073f84d4c8692) Bug: 916514 Change-Id: I250503b85de4a92ec94f69ae41ddb2c4af1fb065 Reviewed-on: https://chromium-review.googlesource.com/c/1395872 Reviewed-by: John Abd-El-Malek <jam@chromium.org> Commit-Queue: Matt Falkenhagen <falken@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#620503} Reviewed-on: https://chromium-review.googlesource.com/c/1401822 Reviewed-by: Matt Falkenhagen <falken@chromium.org> Cr-Commit-Position: refs/branch-heads/3626@{#619} Cr-Branched-From: d897fb137fbaaa9355c0c93124cc048824eb1e65-refs/heads/master@{#612437}
,
Jan 9
Merged, will watch builders.
,
Jan 9
This bug occurs when a service worker gets a fetch event for a request for a PDF and provides a response with respondWith(). So a potential workaround for sites is to not call respondWith() for PDF URLs and let the request fall back to network.
,
Jan 9
This is fixed in Canary 73.0.3665.0 and should be fixed in the next Beta 72 release.
,
Jan 9
Thanks for the hard work falken and shimazu, looks like this one wasn't too easy to track down. Good to hear this is solved per v72.
,
Jan 11
,
Jan 21
(2 days ago)
|
||||||||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||||||||
Comment 1 by rick.lub...@cofano.nl
, Dec 19