Safari 11 print issues

[LucasHill]

Safari 11 seems to have issues around some part of the implementation of printThis. Sometimes it'll prompt the user to ensure if you want to print or not, and after hitting yes it has inconsistent results. It'll either work fine, print a blank page, never display the print dialog, or even crash. It kind of feels like a bug in safari but maybe it can be worked around.

==================================================================== I use printThis in an ember addon. There's a demo below that reproduces the issue but if desired I can make a vanilla print this demo to show it off.

https://lucashill.github.io/ember-print-this/

====================================================================

Steps to reproduce the problem

1. ... Try to print

====================================================================

What is the expected behaviour?

... print dialog displays with content

====================================================================

What is the observed behaviour?

... inconsistent as described above

====================================================================

When you set debug:true and inspect the iframe, what do you see?

... I can try this later sorry.

====================================================================

More Details

• Which browsers/versions does it happen on? Safari 11
• Which printThis version are you using? 1.12

[nip3o]

I can confirm this as well (Safari 11.0.1). I also found another issue in a similar jQuery plugin for printing (https://github.com/DoersGuild/jQuery.print/issues/78), this is probably triggered by the same root cause.

Printing seems to work fine the first time page is loaded, but when trying to print more than one time without reloading the page in between, Safari shows the following dialog:

...and no matter what the user select, nothing else appears and nothing is printed.

I believe this is basically a bug in Safari.

[oculus42]

You only receive this notification if you cancel the print. If you actually print or use the Save as PDF features, you continue to get the print dialog. Once you cancel print, Safari asks the next time.

The failure to print or print the complete content is due to the printThis iframe being removed by a timeout set before the alert, which stops execution but does't change the JavaScript timers. If you add debug: true to the configuration, you get the print dialog after the alert.

This is presumably protection against pages popping up multiple print requests. We may be able to detect this condition and avoid removing the print iframe, but I do not have a clear mechanism to pursue at this time.

[mhulse]

Can anyone think of any reasons why using debug: true might be problematic for a production site?

Adding this option fixed the issue in Safari, and I don't see much reason why I couldn't just roll with this on a production site until this issue gets patched?

Wondering why this option fixes Safari? What part of the code base related to debug makes Safari happy? Couldn't that part be incorporated into the non-debug codebase to allow for Safari users to print after hitting cancel?

Thanks so much for this useful tool!

[mhulse]

Ah, I see that debug adds visible iframes to the body. This seems to fix it:

/* https://github.com/jasonday/printThis/issues/137 */
body > iframe[name="printIframe"] {
    position: absolute;
    top: -999em;
    left: -999em;
}

Also, maybe we could use JS to remove the iframe after printing ... Going to use CSS option above for now.

[jasonday]

@mhulse I think your particular issue is separate from OP's. One thing you could try is to increase the printDelay option. My guess is that in your scenario, the print iframe needs more time to build. Additionally, we do remove the iframe programattically after print - https://github.com/jasonday/printThis/blob/master/printThis.js#L257

[mhulse]

@mhulse I think your particular issue is separate from OP's. One thing you could try is to increase the printDelay option. My guess is that in your scenario, the print iframe needs more time to build. Additionally, we do remove the iframe programattically after print - https://github.com/jasonday/printThis/blob/master/printThis.js#L257

Ahhh, interesting! That's a great idea, thanks! I'll give it a try.

I really appreciate the help and thanks so much for this awesome plugin! Printing is such a pain in the @rse... Nice to have a tool like this that requires minimal effort to make things look good. :octocat:

[jean-moldovan]

Maybe we can utilize matchMedia on Safari to detect when to remove an element:

      const mql = window.matchMedia('print')

      mql.addListener(() => {
        if (!mql.matches) {
          removePrint() // < - fires when dialog is closed??
          console.log('remove')
        }
      })

Needs a bit more testing though.

[jfdnc]

@jasonday Has there been any progress on this issue? I'm currently using printThis in an Ember addon and having the exact same issue as the OP. As has been noted, this seems to be an issue with Safari. Is there a known workaround or has this issue fallen through the cracks?

[nip3o]

I was able to reproduce it the other day with a recent version of Safari, so it still seems to be present. As previously said it only happens when first canceling a print and then trying to print again, so it appeared a lot for us during development, but we haven't had any customers reporting it in production.