Rolling back to 64 and everything works again.

The warning is actually about the PDF viewer in the Print Preview page, and will show up if you inspect print preview on any webpage. See bug 735633. This is likely unrelated to this issue.

Can you provide a link to a sample page that demonstrates the problem? There is probably something specific to that page that is causing it to be rendered differently for printing in 65 vs 64. There is also  bug 819327 , which sounds similar, but we won't know if this is the same issue or not without a sample page to test.

I can give you access to my training system which shows the same behaviour but would prefer not to expose credentials here.

How can I send them? or who to? 

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

You can send them to me. If I can reproduce the issue with your test case, I will try running a bisect from 64 to 65 to see where exactly it broke.

With the test page and credentials from sijones2010, I can reproduce the issue on Linux, so adding label and changing status to Untriaged. I strongly suspect this is a duplicate of  bug 819327 , as the bisect result was:

You are probably looking for a change made after 524503 (known good), but no later than 524506 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/36312fccc6b5f9bba0fa427d6b9756daad3b94e6..75c1af03e20798bbcd01ec14945a9d040c52be92

which includes this CL, https://crrev.com/c/830667. That CL appears to be the original, and the re-land of it was found by the bisect for the other bug.

I also was able to inspect the sample page, and it has an (invisible) iframe that has an ID indicating it is probably what is being printed when the page's print button is clicked. That iframe is styled with display:none, as was the case for the test page in  bug 819327 .

+erikchen@ to confirm/determine next steps.

> I also was able to inspect the sample page, and it has an (invisible) iframe that has an ID indicating it is probably what is being printed when the page's print button is clicked. That iframe is styled with display:none, as was the case for the test page in   bug 819327  .

Thanks for investigating. I'm surprised that this has ever worked before. It looks like this is a hack that some developers employed to print different contents than what's being displayed on the page. I believe that like  Issue 819327 , this should be a WontFix.

I know you see it as a hack but am not sure if there is any other way, i didn't develop the code so i don't know if there is.

All it is doing is printing a receipt - it is showing the Point of Sale system then clicking print it must be changing the content in some way to then print a receipt.

It works fine in other browsers so i suppose i'll have to switch then.

Thanks for your time.

Comment 14: Please see  bug 819327 , which has been re-opened to track this issue.