When one uses the print button, the page (node/n) is replaced by the printer-friendly version (print/n); one must use the Back button to redisplay the original page. This doesn't happen with the PDF function. We've tried using the option to open the print function in a new window, but that doesn't happen (the link doesn't contain a target directive). This has been tested with Chrome, Firefox, and IE.

Comments

jcnventura’s picture

Status: Active » Postponed (maintainer needs more info)

Are you really using 7.x-2.x? If so, there's a @todo above the line that handles that for some reason..

pbfleetwood’s picture

Yes. We're using 7x.2x because we need to have the links displayed in a block, which is not a 7.x-1.0 option.

We'd love to see that @todo become a @todone, but we're too weak on PHP @todoit ourselves.

BTW, what you've done with the new branch is great.

jcnventura’s picture

Title: Printer-friendly page remains after printing » Backport the block-only option from 2.x to 1.x
Category: support » feature
Status: Postponed (maintainer needs more info) » Active

It's already a @todone, just not yet committed.

The block link is already present in the 7.x-1.x version, but it only activates if the link or content option was selected. I'll shift this issue's focus as a request for a backport of that from 7.x-2.x.

The 7.x-2.x is not stable for use, and I'd prefer not to spend any time answering issues for that yet.

pbfleetwood’s picture

Thanks so much for your quick response and explanation.

jcnventura’s picture

Version: 7.x-2.x-dev » 7.x-1.x-dev
Status: Active » Fixed

Actually, I've done this already back in May 8th.. I just didn't remember it. Try the 7.x-1.x-dev and tell me what you think of it...

pbfleetwood’s picture

I switched from 7.x-1.0 to 7.x-1.x-dev and tried it out with Firefox and my preferred settings, and it worked perfectly. Then I tried another browser, and another, and realized that I'd have to test much more extensively.

I primarily tested the settings that govern how the tab or window is opened and closed, using the Windows versions of the following browsers (ordered by their rankings in our site's analytics). I tested with the output going to either a printer or to CutePDF, which made no difference to the way the browsers performed.
Internet Explorer 8 (58% of users)
Safari 5.1.5 (17%)
Firefox 3.6 (11%)
Chrome 14 (9%)
Opera 11.51 (0.1%)

For each combination of settings all caches were flushed and the test page was refreshed in each browser. The choice of New window method made no difference to the results.

Annoyingly, as usual, all of the browsers wanted to do things in their own special ways. Firefox was the best behaved. Chrome is usually well behaved, but failed badly under one combination of settings (the ones I prefer, of course :/ ). IE was unpredictable; Safari had some failures; and Opera was a total disaster (no surprise there).

Since the results were so inconsistent, I would not be at all surprised if you were to get completely different results. In one way or another, all browsers suck.

  1. Without Open the printer-friendly version in a new window and
    Without Close window after sending to printer
    OR
  2. Without Open the printer-friendly version in a new window and
    With Close window after sending to printer
    • IE, Firefox, and Chrome:
      • The printer-friendly page opens in the current tab.
      • The print dialog tab (Chrome) or dialog box (Firefox, IE) opens. Upon printing or cancelling, the print dialog closes, but the printer-friendly page remains in the current tab and the back button must be clicked to return to the original page.
    • Safari:
      • The print dialog box opens.
      • Upon printing or cancelling(!), the print dialog closes and the printer-friendly page opens in the current window, then the back button must be clicked to return to the original page.
    • Opera:
      • The printer-friendly page opens in the current tab.
      • No print dialog opens, so one must select print from the browser menu, then the back button must be clicked to return to the original page.
  3. With Open the printer-friendly version in a new window and
    Without Close window after sending to printer
    • IE, Firefox, and Chrome:
      • The printer-friendly page opens in a new tab (Chrome, Firefox) or window (IE).
      • The print dialog tab (Chrome) or dialog box (Firefox, IE) opens. Upon printing or cancelling, the print dialog closes, but the printer-friendly tab or window remains open and must be closed manually.
    • Safari:
      • A blank window opens.
      • The print dialog box opens.
      • Upon printing or cancelling, the print dialog closes and the printer-friendly page opens in the blank window, which must be closed manually.
    • Opera:
      • The printer-friendly page opens in a new tab.
      • No print dialog opens, so one must select print from the browser menu, then close the tab displaying the printer-friendly page.
  4. With Open the printer-friendly version in a new window and
    With Close window after sending to printer
    • IE:
      • Either:
        • The printer-friendly page opens in a new window.
        • The print dialog box opens.
        • Upon printing or cancelling, the print dialog and the new window with the printer-friendly page close.
          OR
        • The printer-friendly page opens in a new window, then closes immediately.
        • The print dialog box does not open.
        • No print output is produced.
    • Safari:
      • A blank window opens.
      • The print dialog box opens.
      • Upon printing or cancelling, both the print dialog and the blank new window close.
      • No print output is produced.
    • Firefox:
      • The printer-friendly page opens in a new tab.
      • The print dialog box opens.
      • Upon printing or cancelling, the print dialog and the new tab with the printer-friendly page closes.
    • Chrome:
      • The printer-friendly page opens briefly in a new tab, but closes before or shortly after the Chrome print dialog opens.
      • The Chrome print dialog page opens, but with the error message "Print is unavailable because the page you were trying to print has been closed."
      • If the printer-friendly tab closed before the print dialog tab opened, then the "Reopen the page" button does not appear beneath the error message, so the print dialog tab must be closed manually and one must try again by clicking the printer icon on the original page.
      • If the printer-friendly tab closed after the print dialog tab opened, then the "Reopen the page" button does appear beneath the error message. When that button is clicked, the printer-friendly page opens in the current (print dialog) tab and remains and a new print dialog tab opens successfully. Upon printing or cancelling, the print dialog tab closes, but the printer-friendly tab remains open and must be closed manually.
    • Opera:
      • A blank tab opens, then closes immediately.
      • No print dialog opens.
      • No print output is produced.
jcnventura’s picture

OK. Setting some things straight:
- Open in new window has a setting (in admin/config/user-interface/print/common) on how it opens. Javascript or target. Depends how XHTML 1.0 compliant you want to be, but now with HTML5 being popular, and no one caring about compliance anymore, maybe the default should change to target. When using JS it calls window.open(this.href)
- Send to printer also uses Javascript (the only way it can ever work), and calls window.print()
- Close window after printing only works when both of the above are active. It uses window.close(). This is documented in that setting's description.

Apparently, send to printer is not working in Opera at all. Other than that:
1 and 2 are OK
3 seems OK, except Safari apparently has a problem with the method you've got configured to open in a new window.
4 reproduces 3, but Chrome is too fast in executing the window.close() before the window.print() is ready.

Finally, this is totally unrelated to the block-only option.. Can you please open a new issue?

pbfleetwood’s picture

Finally, this is totally unrelated to the block-only option.. Can you please open a new issue?

Yes, but it is totally related to the original support request issue that I opened. You asked what I thought, so I invested the time in testing it. Shouldn't have bothered, I guess; won't bother again. :(

jcnventura’s picture

Title: Backport the block-only option from 2.x to 1.x » Window open + print + close, has some issues in non-Firefox browsers
Status: Fixed » Active

Oh, please bother... It's just that when I look at the list of stuff, I see activity on something called "Backport the block-only option from 2.x to 1.x", which should no longer be on my to-do list.

However, since you and I seem to be the only ones on this thread, we can continue reusing this one. Usually I prefer to open new issues when the initial issue is solved, as keeping it open will only annoy all the other subscribers.

My development setup is Linux-only, and I trust Drupal and jQquery to keep all the browser-specific stuff out, so I usually only test with Firefox.. I do appreciate that someone has the patience to test all the others. I've seen on the Web that Opera is indeed "doing it's own thing" in this matter.

Finally, can I ask you to test Safari with both the 'open new-window' methods?

Thanks and sorry for the tone at the end of my last post.

pbfleetwood’s picture

My last message was a little testy, I know. Up too late; up too early; no coffee. I do beg your pardon.

I'll be happy to test Safari, I'll get to it tomorrow or Saturday.

Cheers :)

pbfleetwood’s picture

So I tried it out over the weekend at home, with completely different results: Chrome worked like a charm, but IE failed completely. I didn't have Safari or Firefox installed -- it's a new PC -- and I didn't really have time to install them because I'm in a big rush to get our site live on time. In a couple of weeks I'll have more time; right now, doing anything that isn't work is an inexcusable luxury. (._.)

jcnventura’s picture

Thanks for your efforts, they're appreciated.

jcnventura’s picture

Status: Active » Fixed

I think I have found the solution to the problem.. Drupal.behaviors runs on DOM ready, which is OK for most jQuery scripts, but in this case, it needs for the document to be fully loaded, before the window.print is called.

I've committed a fix to dev (tested in IE9, Firefox 12 and Opera 11.64).

pbfleetwood’s picture

Thank you very much. I'm looking forward to trying out the new dev version as soon as time allows. :)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

shaisamuel’s picture

Issue summary: View changes

I love the model, and appreciate the tenacity of its developers.
I have similar issues with D7.36 and Printer, email and PDF versions 7.x-2.0 (mPDF 4.4), jQuery update 1.7:

  • Open in new window of Printer Friendly Version open the print version on the same tab.
  • Sent to Printer works fine.
  • Close window after printing close the window without waiting for user confirmation of the printer.
Vako’s picture

Category: Feature request » Support request
Priority: Normal » Major
Status: Closed (fixed) » Active

I'm having the same issue with Chrome browser. Firefox and IE work fine.
Here are the details:
- When I click on Print, a dialog window opens up and then closes, hence doing nothing. If I disable Send to Printer option then Printing works with Chrome as well. But I prefer to have that option, if possible.

- When I click on PDF, Chrome locks-up and doesn't produce any PDF (this works for the other browsers)
I have tried all options for PDF but nothing works for Chrome.
I am using domPDF and it's correctly configured since it works for other browsers.

bisonbleu’s picture

I have similar issue as in #16

Open PDF in new browser window does not work i.e. PDF is opened in the same window.