Requests for picture sources with media="print" are cancelled prior to printing
Reported by
rha...@arcstone.com,
Aug 23 2017
|
|||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/60.0.3112.78 Chrome/60.0.3112.78 Safari/537.36 Steps to reproduce the problem: Create a simple picture element like so: <picture> <source srcset="mdn-logo-wide.png" media="print"> <img src="mdn-logo-narrow.png" alt="MDN"> </picture> What is the expected behavior? When printing, the source with media=print (mdn-logo-wide.png) should have been loaded and printed. What went wrong? When printing (preview/pdf generation), the media=print image (mdn-logo-wide.png) is never loaded, and the original, default image (mdn-logo-narrow.png) is included in the printed output. I can see Chromium attempt to load the images from the Network panel, however these requests get marked "(cancelled)" and never complete. Did this work before? No Does this work in other browsers? No Firefox doesn't even try to load the print images. https://bugzilla.mozilla.org/show_bug.cgi?id=1393118 Chrome version: 60.0.3112.78 Channel: stable OS Version: Ubuntu 17.04 Flash Version:
,
Aug 24 2017
Have you tried IE/Edge or any other browser besides Firefox to see if this works? Can you attach a zip file or tarball with a complete set of HTML/CSS/images so it's easier to reproduce the bug?
,
Sep 15 2017
This doesn't affect images only, but all kinds of resources that are exclusive to the print version of a webpage. While trying to work around the problem I've come up with a test page (including test results for other browsers). => http://demos.scheurle.info/browsers/print-resources/
,
Sep 19 2017
Putting this in the Blink>CSS triage queue. I tried the webpage in comment 7. The behavior is indeed inconsistent across browsers, and when caching is involved.
,
Sep 20 2017
,
Sep 20 2017
I don't think bisecting is needed as this never worked, per original bug report.
,
Sep 21 2017
,
Sep 21 2017
Given this bug applies to all resource loading (fonts, images), I think that Loader is likely the source of the problem. I recognise this is like passing the hot potato.
,
Oct 23 2017
The loading code cancels the request as requested. blink::WebAssociatedURLLoaderImpl::WebAssociatedURLLoaderImpl(blink::Document *, const blink::WebAssociatedURLLoaderOptions &) this = 0xb378d729e00 virtual void blink::WebAssociatedURLLoaderImpl::LoadAsynchronously(const blink::WebURLRequest &, blink::WebAssociatedURLLoaderClient *) this = 0xb378d729e00 virtual void blink::WebAssociatedURLLoaderImpl::Cancel() this = 0xb378d729e00 #0 0x7fcc68061ce7 base::debug::StackTrace::StackTrace() #1 0x7fcc620c94ba blink::WebAssociatedURLLoaderImpl::Cancel() #2 0x7fcc664da737 content::PepperURLLoaderHost::OnResourceMessageReceived() #3 0x7fcc63822abc ppapi::host::ResourceMessageHandler::RunMessageHandlerAndReply() #4 0x7fcc63821f5c ppapi::host::ResourceHost::HandleMessage() #5 0x7fcc6381fb08 ppapi::host::PpapiHost::OnHostMsgResourceCall() #6 0x7fcc6381f93c _ZN3IPC8MessageTI30PpapiHostMsg_ResourceCall_MetaNSt3__15tupleIJN5ppapi5proxy25ResourceMessageCallParamsENS_7MessageEEEEvE8DispatchINS4_4host9PpapiHostESC_vMSC_FvRKS6_RKS7_EEEbPSF_PT_PT0_PT1_T2_ #7 0x7fcc6381f846 ppapi::host::PpapiHost::OnMessageReceived() #8 0x7fcc6379c7ec ppapi::proxy::HostDispatcher::OnMessageReceived() #9 0x7fcc673a8c25 IPC::ChannelProxy::Context::OnDispatchMessage() #10 0x7fcc673b369f IPC::SyncChannel::ReceivedSyncMsgQueue::DispatchMessages() #11 0x7fcc673b4e1a IPC::SyncChannel::OnDispatchEventSignaled() #12 0x7fcc680c497a base::AsyncCallbackHelper() #13 0x7fcc680c4f8f _ZN4base8internal7InvokerINS0_9BindStateIPFvPNS_4FlagENS_12OnceCallbackIFvPNS_13WaitableEventEEEES7_EJNS0_18RetainedRefWrapperIS3_EES9_S7_EEEFvvEE7RunOnceEPNS0_13BindStateBaseE #14 0x7fcc68062797 base::debug::TaskAnnotator::RunTask() #15 0x7fcc611b87ef blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue() #16 0x7fcc611b68a9 blink::scheduler::TaskQueueManager::DoWork() #17 0x7fcc68062797 base::debug::TaskAnnotator::RunTask() #18 0x7fcc68088aa4 base::MessageLoop::RunTask() #19 0x7fcc68089017 base::MessageLoop::DoWork() #20 0x7fcc68089c5a base::MessagePumpDefault::Run() #21 0x7fcc680af4b5 base::RunLoop::Run() #22 0x7fcc66400a34 content::RendererMain() #23 0x7fcc66518914 content::RunZygote() #24 0x7fcc66519b12 content::ContentMainRunnerImpl::Run() #25 0x7fcc6854145c service_manager::Main() #26 0x7fcc66518652 content::ContentMain() #27 0x558c1b41c1c4 ChromeMain #28 0x7fcc5cf24f45 __libc_start_main #29 0x558c1b41c029 <unknown>
,
Oct 23 2017
yhirano: For those of us unfamiliar with Blink, how can we tell what is being cancelled when WebAssociatedURLLoaderImpl::Cancel() gets called? I'll check the other end to figure out who is sending the request in the first place.
,
Oct 24 2017
WebAssociatedURLLoader::LoadAsynchronously takes a WebURLRequest which contains a URL. Does this answer your question?
,
Oct 24 2017
yhirano: So in WebAssociatedURLLoaderImpl::LoadAsynchronously(), I added: LOG(ERROR) << "LoadAsynchronously " << this << " " << request.Url().GetString().Utf8(); and in WebAssociatedURLLoaderImpl::Cancel(), I added: LOG(ERROR) << "Cancel " << this; Then I loaded http://demos.scheurle.info/browsers/print-resources/, opened Print Preview, and examined the |this| value in the logs. All of the Cancel() calls have |this| values that correspond to chrome://print/1/NN/print.pdf URLs from LoadAsynchronously(). So that's Print Preview internal URLs, and not web resources, being cancelled.
,
Oct 24 2017
> #16 You're right, thanks. void blink::ResourceLoader::ScheduleCancel() url = https://www.google.co.jp/images/branding/googlelogo/2x/googlelogo_color_272x92dp.png, this = 0xa9d3ab91e0 #0 0x7f7f816bcce7 base::debug::StackTrace::StackTrace() #1 0x7f7f7a86279d blink::ResourceLoader::ScheduleCancel() #2 0x7f7f7bc0bc51 blink::ImageResource::AllClientsAndObserversRemoved() #3 0x7f7f7a84e739 blink::Resource::DidRemoveClientOrObserver() #4 0x7f7f7bc0d7f8 blink::ImageResourceContent::RemoveObserver() #5 0x7f7f7bbec399 blink::ImageLoader::DoUpdateFromElement() #6 0x7f7f7bbec9b5 blink::ImageLoader::UpdateFromElement() #7 0x7f7f7b88b19a blink::HTMLImageElement::SelectSourceURL() #8 0x7f7f7b89b25a blink::HTMLPictureElement::SourceOrMediaChanged() #9 0x7f7f7b6b65e8 blink::ScriptedAnimationController::ServiceScriptedAnimations() #10 0x7f7f7bc32f93 blink::PageAnimator::ServiceScriptedAnimations() #11 0x7f7f7b7c3fef blink::WebViewImpl::BeginFrame() #12 0x7f7f7fa09b19 content::RenderWidgetCompositor::BeginMainFrame() #13 0x7f7f7e704a42 cc::ProxyMain::BeginMainFrame() #14 0x7f7f7e703d91 _ZN4base8internal7InvokerINS0_9BindStateIMN2cc9ProxyMainEFvNSt3__110unique_ptrINS3_28BeginMainFrameAndCommitStateENS5_14default_deleteIS7_EEEEEJNS_7WeakPtrIS4_EENS0_13PassedWrapperISA_EEEEEFvvEE7RunImplISC_NS5_5tupleIJSE_SG_EEEJLm0ELm1EEEEvOT_OT0_NS5_16integer_sequenceImJXspT1_EEEE #15 0x7f7f816bd797 base::debug::TaskAnnotator::RunTask() #16 0x7f7f7a881fdf blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue() #17 0x7f7f7a880099 blink::scheduler::TaskQueueManager::DoWork() #18 0x7f7f816bd797 base::debug::TaskAnnotator::RunTask() #19 0x7f7f816e3aa4 base::MessageLoop::RunTask() #20 0x7f7f816e4017 base::MessageLoop::DoWork() #21 0x7f7f816e4c5a base::MessagePumpDefault::Run() #22 0x7f7f8170a555 base::RunLoop::Run() #23 0x7f7f7faccee6 content::RendererMain() #24 0x7f7f7fbe6b04 content::RunZygote() #25 0x7f7f7fbe7d02 content::ContentMainRunnerImpl::Run() #26 0x7f7f81b9c45c service_manager::Main() #27 0x7f7f7fbe6842 [32051:32083:1024/100230.179139:ERROR:service_manager.cc(157)] Connection InterfaceProviderSpec prevented service: content_renderer from binding interface: blink::mojom::ReportingServiceProxy exposed by: content_browser content::ContentMain() #28 0x559fdc88f1c4 ChromeMain #29 0x7f7f765ebf45 __libc_start_main #30 0x559fdc88f029 <unknown> virtual void blink::WebAssociatedURLLoaderImpl::LoadAsynchronously(const blink::WebURLRequest &, blink::WebAssociatedURLLoaderClient *) request = chrome://print/1/0/print.pdf, this = 0x30e0d3a10bc0 virtual void blink::WebAssociatedURLLoaderImpl::Cancel() this = 0x30e0d3a10bc0
,
Oct 24 2017
ImageLoader cancels the request (as shown in #17) because LocalFrameView::MediaType() returns "screen" (instead of "print") and hence the media type doesn't match. I see LocalFrameView::SetMediaType("screen") called from LocalFrameView::SetPrinting(false) but I don't know why.
,
Dec 7 2017
,
Dec 7
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 11
|
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by manoranj...@chromium.org
, Aug 23 2017Labels: Needs-Triage-M60