Note: Issue is seen on Linux (14.04 LTS) and Mac (10.11.6, 10.12.1)OS.

Manual bisect:
Good build: 58.0.3008.0 
Bad build: 58.0.3009.0

Deleted: Print.jpg 96.3 KB

	Print.jpg 96.3 KB View Download

Able to reproduce the issue and below are the bisect details obtained using bisect-per revision:

Bisect Info:
============
Good build: 58.0.3008.0 
Bad build: 58.0.3009.0

Bisect Url: https://chromium.googlesource.com/chromium/src/+log/5f66fed882f55cbc69eed1fb1d06f562c6ed5d01..698a09b008f29b551de793864a045f2ff0578857
Change URL: https://chromium.googlesource.com/chromium/src/+/698a09b008f29b551de793864a045f2ff0578857

@fmalita: Assigning to you, request you to please take a look into it. Adding blocker label. Please remove if not the case.

Thanks.!

The "before" version is not correct either: that's supposed to be a soft shadow, not a sharp border.

We no longer draw shadows when printing, because they're not supported in the PDF backend and most of the time they produce undesirable results (see  issue 174583 ,  issue 127651 ).  In this particular case the pop-up doesn't have an actual border, so dropping the degenerate shadow looks worse.

I would argue this is an UI bug: the popup should have a printable border, and not rely on shadows for delimitation.  Not sure what the best thing to do at this point is though: revert the shadow change while the UI gets updated (which would regress printing of content shadows), or punt to UI and leave as is.

schenney/chrishtr - any thoughts?

Deleted: screenshot.png 27.8 KB

	screenshot.png 27.8 KB View Download

The UI should be changed. Relying on broken shadow painting is not the right way to paint a border.

I don't think this should cause reversion of the shadow printing patch. It's not very important that someone be able to print this page.

We should revisit this if we get lots of reports of sites relying on the old bad behavior in printing critical situations.

Friendly ping!!

Still we are able to reproduce the issue on latest Canary#58.0.3017.0.
Could you please look into this issue @ update the thread.
Thank you.

Able to reproduce this issue on Mac 10.12.3 with chrome dev #58.0.3025.0, 
Since it has a release block-stable label, fmalita@ could you please provide an update the issue.

This is an issue with the UI. We are not going to revert the printing change in this situation and it should not be a release block because printing this content is not very important.

Downgrading priority and waiting for WebUI folks to triage.

fmalita/schenney: how hard would it be to draw shawdows as fully opaque in the
PDF backend?

I'm not sure on what the pdf backend can do. halcanary@ would probably know.

I would be concerned, however, about showing different results in the preview and the printed result. At least right now the representations match.

I don't mean painting differently, I mean interpreting a shadow as opaque in the
skia rasterizer.

Sorry, I got it backwards. We could paint the shadow as a solid rect when in printing painting mode. I.e. instead of not drawing anything, draw something to match the printed output.

Depends whether we think people would prefer no shadows or black shadows on their printed content in the numerous cases where websites don't have CSS media rules.

> I'm not sure on what the pdf backend can do. halcanary@ would probably know.

https://skia.org/user/sample/pdf#limits

Skia folks: Do you want to do anything about this? I imagine from the WebUI side, their answer is chrome://extensions is not really meant to be printed.

Shadows have no native representation in PDF.  If you want a shadow, draw an image of a shadow.  If you want an un-shadowed box, draw a box without a MaskFilter.

This doesn't really seem like a problem with the extensions platform.

I'd also say this isn't a problem with the webui page - it seems odd that web devs would have to know the innards of how skia or printing in chrome works to know whether or not something very visible on the webpage will be lost in the printing...

I suppose this is a decision Blink should make.

Couldn't shadows be rendered on the fly into images in the PDF renderer?

 Issue 723973  has been merged into this issue.

See  issue 723973 . It seems that setting is_printing to false on the
GraphicsContext changes painted output such that the shadow still appears in 
some form on the printed page. Therefore it seems we can implement a
workaround in GraphicsContext.

Oh I'm being dumb. Setting IsPrinting to false will just amount to reverting
https://codereview.chromium.org/2689733002.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/de5f24293bb231a3d770b731b0aadf549cab86ae

commit de5f24293bb231a3d770b731b0aadf549cab86ae
Author: Florin Malita <fmalita@chromium.org>
Date: Sat Jun 17 15:17:09 2017

Reenable box shadows when printing

Skia's PDF backend now supports blur masks!

(this is a revert of http://crrev.com/2689733002/)

BUG= chromium:127651 , chromium:354073 , chromium:691440 

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: Id43393e48aa674c8a3a69c607c3512138d998dff
Reviewed-on: https://chromium-review.googlesource.com/538335
Commit-Queue: Florin Malita <fmalita@chromium.org>
Reviewed-by: Chris harrelson <chrishtr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#480302}
[modify] https://crrev.com/de5f24293bb231a3d770b731b0aadf549cab86ae/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/de5f24293bb231a3d770b731b0aadf549cab86ae/third_party/WebKit/Source/core/paint/BoxPainterBase.cpp