Background images in printed pages are white instead of transparent
Reported by
kup...@gmail.com,
Oct 19 2016
|
||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.59 Safari/537.36 Steps to reproduce the problem: 1. Open index.html (see attached zip file). 2. Press ctrl+a to select all text. 3. Click text by right mouse button and select "Print..." 4. Text of last paragraph will be overlapped by "empty" image. What is the expected behavior? Text on preview page should not be overlapped by images. What went wrong? Seems like Chrome uses different modes for Print of selected text and print of whole page. In first case not all @media print CSS rules works. When you change options on preview page (check/uncheck Background graphics or check/uncheck Selection only) preview PDF becomes different. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 54.0.2840.59 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 23.0 r0
,
Oct 23 2016
Check 2nd word in last paragraph, pls. It should be "ipsum" but white image hides part of word.
,
Oct 24 2016
Able to reproduce the issue on windows-7, Mac 10.11.4 and Linux Ubuntu-14.04 using chrome stable version 54.0.2840.71 and canary 56.0.2899.0 This is regression issue broken in M51.Please find the bisect information as below Narrow Bisect:: =============== Good :51.0.2701.0 -- (build revision 385337) Bad:: 51.0.2702.0 -- (build revision 385602) ChangeLog: ================ https://chromium.googlesource.com/chromium/src/+log/95a6fd5887a9f1101be12815863fe2a9e4a07fdd..1d7eb2b891ccbe5ec16f7baf1751f5c223db0c7f Possible suspect ================== 37a62ed4183b7ff3c7711650f580ab3b7973f046 Review URL: https://codereview.chromium.org/1865603004 alancutter@ could you please look into this issue if it is related to your change,else please help us in finding the appropriate owner for this issue. Thanks,
,
Oct 26 2016
Looks like it's due to the line "m_cachedImage = StyleInvalidImage::create(url());" in CSSImageValue.
,
Oct 26 2016
,
Oct 26 2016
Created minimal test case: https://jsfiddle.net/swxckne3/ <!DOCTYPE html> <style> #target { position: absolute; width: 100px; height: 100px; background: url("filesystem://"); } </style> <div id="target"></div> Open print preview, the text on this page should not be cut off at the start. https://codereview.chromium.org/1865603004 caused us to store computed FillLayer image values even if they can't be resolved to an image resource. Instead of nullptr we store StyleInvalidImages. Seems like something is seeing a non-null value for the background FillLayer and attempts to paint it but only in print preview for some reason.
,
Nov 3 2016
,
Nov 3 2016
nainar: Would you be willing to investigate this one from here? I think I wouldn't benefit as much from digging into print code as you would.
,
Nov 3 2016
Sure will take a look at it and update here if I can find anything.
,
Nov 17 2016
Still able to reproduce the issue on win10 chrome version 56.0.2922.0 nainar@, Could you please provide an update on this
,
Nov 25 2016
nainar@ Friendly reminder!! We are able to reproduce the issue on Windows 7 with latest stable# 54.0.2840.99 & Canary versions-57.0.2931.0. Please check this issue & update on the same. Thank you.
,
Nov 25 2016
Hi, sorry for missing the message. I have just started looking at this and other printing related issues this week. I will update regarding any findings that I have as soon as I have something.
,
Jan 11 2017
Just to update, still able to reproduce this issue on Mac 10.12.2 using latest canary #57.0.2977.0. nainar@ - Gentle Ping...!! Could you please have a look into this issue. Thanks...!!
,
Feb 8 2017
,
Feb 21 2018
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. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 6 2018
This is not something we can fix on the printing side. Blink is painting the contents. Adding the Blink>Paint component for triaging.
,
Mar 6 2018
,
Mar 6 2018
Works properly now. |
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by sureshkumari@chromium.org
, Oct 21 2016Labels: Needs-Feedback OS-Linux OS-Mac
208 KB
208 KB View Download