Attached a screen capture of the steps in the comment above (file: ChromePrintIssue480p.mov)

Thanks for the report!  I can confirm that "Open in Preview" doesn't work on Mac Stable 67.0.3396.99 for me when I followed your repro steps.  Starting with a fresh profile typically doesn't apply any field trials, which would be fetched and applied on next restart, so this is likely due to a field trial that was activated in M67.

I think this is related to site isolation.  I tried setting chrome://flags/#site-isolation-trial-opt-out to "Opt out", restarting, and repeating the repro steps, and "open the preview" started to work.  Can you confirm if setting this flag solves your issue?

weili@ or thestig@: would you be able to take a look?  There's an OOPIF as well as Flash on the page that's trying to print, and it seems something is going wrong with site isolation printing support.  This seems to occur regardless of whether chrome://flags/#use-pdf-compositor-service-for-print is enabled.

I can reproduce this on Mac Canary without the need to relaunch. I don't think bisecting will find anything useful.

@alex: Thanks for the workaround. Yes. Setting this flag solves this issue.

I can turn off Print Preview altogether in Chromium and still reproduce this by going straight to the Mac native print dialog. So this isn't an issue in the Print Preview to system print dialog transition.

The error message I see in my debug build is PdfCompositorImpl::CompositeToPdf() failing with "No page is read" but I suspect the bigger problem is the code in the PDF compositor should not even be called in this case. Need to keep digging.

PrintingPdfContent() from r542630 checks URLs, but that does not work for Flash content.

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

commit 3764d52b7ff29111f5043e5efcfcc2e6d0ee6dba
Author: Lei Zhang <thestig@chromium.org>
Date: Tue Jul 24 22:31:11 2018

Remove printing::PrintingPdfContent().

PrintingPdfContent() uses URLs to figure out if the content to be
printed is PDF or not. This does not work when printing Flash content.
Go back to checking PrintSettings::is_modifiable(), which already works
correctly on Mac. On Windows and Linux, the "is modifiable" setting
needs to be preserved when getting settings from the user in the native
print dialog.

BUG= 859481 

Change-Id: I674cf3c0f38b87c17fb6d2ca30ebae842c260d8c
Reviewed-on: https://chromium-review.googlesource.com/1146024
Reviewed-by: Rebekah Potter <rbpotter@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#577712}
[modify] https://crrev.com/3764d52b7ff29111f5043e5efcfcc2e6d0ee6dba/chrome/browser/printing/print_view_manager_base.cc
[modify] https://crrev.com/3764d52b7ff29111f5043e5efcfcc2e6d0ee6dba/chrome/browser/printing/print_view_manager_common.cc
[modify] https://crrev.com/3764d52b7ff29111f5043e5efcfcc2e6d0ee6dba/chrome/browser/printing/print_view_manager_common.h
[modify] https://crrev.com/3764d52b7ff29111f5043e5efcfcc2e6d0ee6dba/chrome/browser/ui/libgtkui/print_dialog_gtk.cc
[modify] https://crrev.com/3764d52b7ff29111f5043e5efcfcc2e6d0ee6dba/printing/printing_context_system_dialog_win.cc

Should be fixed in 70.0.3502.0 and newer.

I reproduced the same problem on Windows when Print Preview is disabled, BTW.

Able to reproduce this issue on Mac OS 10.13.3 on the reported version 67.0.3396.99 and the issue is fixed on the latest Canary 70.0.3502.0 as per the original comment.

Able to print through system dialog on relaunch.
Attached is the screen cast for reference.

Hence adding TE verified labels as the fix is working as intended.

Thanks..

Deleted: 859481-M70.mp4 6.3 MB

	859481-M70.mp4 6.3 MB View Download