Print.js: In the latest version of chrome, it can not work as expected

[zsirfs]

In Safari, it is normal. But in chrome, print html content, it can not recognize the style. How is it?

[zsirfs]

system： MACOS 10.0+
browser: Chrome 59.0+

[joster-dev]

This issue is probably related to my issue #54

[zsirfs]

@joster422 I have a good idea to print and work well in Chrome.

``javascript function print(id, style) { let printHtml = document.querySelector(#${id}).innerHTML let iframe = document.createElement('iframe') let div = document.createElement('div') div.innerHTML = printHtml document.body.appendChild(iframe) iframe.contentDocument.body.appendChild(div) let tagStyle = document.createElement('style') tagStyle.innerHTML = style; iframe.contentDocument.head.appendChild(tagStyle) if (navigator.userAgent.toLowerCase().indexOf("firefox") != -1) { iframe.contentWindow.print(); } else { iframe.contentWindow.document.execCommand('print', false, null); } document.body.removeChild(iframe) }

[zsirfs]

@joster422 to try

[yuanwowo]

I make it work by adding this line
iframeElement.setAttribute('style', 'display:block;')
before iframeElement.focus() in finishPrint function

[zsirfs]

@yuanwowo my idea is printed of html page.

[joster-dev]

@tstrilogy its a good solution but then you see the new iframe content window in the background of the print model. One of the selling points of print.js is the ability to print the page using the print model without having another window open up.

@yuanwowo this fixes the issue. Going to try to merge this up. Thank you so much!

[joster-dev]

Should mention that the solution had an issue, the iframe would still be visible with the display being "block" now instead of "none".

iframeElement.setAttribute('style', 'display:block; position: absolute; top: -9999px; left: -9999px;')

this makes it not display and takes it out of the flow of the document so your scrollbars arn't affected

[crabbly]

Hey guys, does anybody know why making the iframe visible fixes the layout issue?

[crabbly]

Looks like this issue is not directly related to a Chrome version, but instead, how the library process the style / css applied to the html element.

Closing this in favor of #74