Not showing the browser's print window when printing an URL

Expected Behavior

Upon clicking print in our application, the print dialog should show and allow us to print the data we send through
...

Actual Behavior

Upon clicking print, nothing appears and you are unable to click on anything on the webpage. You have to refresh to get it back to normal
...

Comments:
We found that it works consistently with early versions of chromium (98 & lower) but version 99 it is hit and miss.
On one device using Chrome or Brave and chromium version 99.0.4484.51, it doesn't produce the print window and on another device, with the same version of chromium it does show the print window.

When we inspect the page, it is producing the iframe with the correct data (we can open this in a new tab, and all the data is fine)

It works fine on Safari and Firefox.

Specifications

Version: ^1.4.1
Platform: MAC and Windows
Browser version: see above

Looks like for me it's working using https://unpkg.com/printd@1.4.1/printd.umd.min.js

https://codepen.io/joseluisq/full/VzRpGb/

Hi, first, thanks so much for your library @joseluisq.
We are having the same issue @conorholgate was reporting.
The main difference with the example provided by @joseluisq is that we are trying to print using printUrl.
Take a look at this example forked from the example you have provided:
https://codepen.io/reynerhl/pen/zYPVmrb

Just to add we are using printUrl too.

I have the same problem. However, it occurs only with the latest Google Chrome version.
Version 99.0.4844.51

As described in the last comments, the problem occurs only when we use printUrl.

@joseluisq Maybe this info helps.

Thanks for reporting guys.
I will try to reproduce the issue with latest Chrome.

Thanks to you for your time. Is a very odd bug because we can't see nothing in console for helping you further.

Good news I found the issue.

Now in Chrome 99 when printing an URL via the printURL method it will hang the browser tab at this point:

printd/src/index.ts

Line 173 in 0336286

const result = contentWindow.document.execCommand("print", false, undefined)

The reason as far I have seen during debugging is because document.execCommand API was deprecated time ago but looks like Chrome 99 has enforced that. BUT the tricky part is that if that is true then why is working for our print() method? So strange.

Anyway, the solutions are:

a. Remove that deprecated contentWindow.document.execCommand("print", false, undefined) API and go directly with contentWindow.print(). Which works on Chrome 99, Safari 15.2, Firefox 97/98 according my tests. Of course this need more tests on Windows browsers and others like Opera etc.
b. Go with contentWindow.print() only if a recent browser is detected so we preserve the old API for old browsers.

Please let me know your thoughts.

Thanks @joseluisq for pointing the issue. It was weird that we have any warning message or something telling us that soon that function will be deprecated.

Now, I'm checking in "Can I use" the browser support for going with the first solution (removing the deprecated function):
https://caniuse.com/mdn-api_window_print

Crazy Shit.
I agree with @ReynerHL and would also recommend that way.

Based on "Can I use", after filtered by "Date relative" availability, seems like the print function was available for most important browsers since a long time ago, so now I'm feel more confortable suggesting going with the first option.

It will also be easier to implement and publish the new release. Hope you are agree with us.

Yes, the first option sounds fine for me and also good that the browser print API is working in all major browsers.

However since this is theoretically a breaking change for browsers like IE 11. In order to don't just break other's people code. I will promote a major version which will allow us to remove the deprecated API in a more safely way and go directly with browser's encouraged print API instead.

Sounds fair, but in case this might help, I would like to let you know that for IE 11 (and perhaps almost all other browsers), execCommand shares pretty close the same support print has.
https://caniuse.com/mdn-api_document_execcommand

But thanks for read our thoughts.

Sounds fair, but in case this might help, I would like to let you know that for IE 11 (and perhaps almost all other browsers), execCommand shares pretty close the same support print has. https://caniuse.com/mdn-api_document_execcommand

But thanks for read our thoughts.

Then it would be great if we could at least give a test. If it works so then it would be fine to just bump a patch version.
But I definitely need your help for testing on IE 11.

Nice, we can try with this. Please, let me know if it helps you for your test or you are actually asking for something different:
https://live.browserstack.com/dashboard#os=Windows&os_version=8.1&browser=IE&browser_version=11.0&zoom_to_fit=true&full_screen=true&resolution=responsive-mode&url=www.google.com&speed=1

Nice, we can try with this. Please, let me know if it helps you for your test or you are actually asking for something different: https://live.browserstack.com/dashboard#os=Windows&os_version=8.1&browser=IE&browser_version=11.0&zoom_to_fit=true&full_screen=true&resolution=responsive-mode&url=www.google.com&speed=1

Great! could you please help with this?
There is already a PR which needs IE 11 test.

I apologies. I hadn't use that platform before and did not know that it is not free. I think we should try another way because they only offer 1 minute per browser.

I apologies. I hadn't use that platform before and did not know that it is not free. I think we should try another way because they only offer 1 minute per browser.

Don't worry, then maybe the others could help.
Please let's continue the discussion on #19.

Fixed on v1.5.1