Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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
Comment #1
jcnventura CreditAttribution: jcnventura commentedAre you really using 7.x-2.x? If so, there's a @todo above the line that handles that for some reason..
Comment #2
pbfleetwood CreditAttribution: pbfleetwood commentedYes. 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.
Comment #3
jcnventura CreditAttribution: jcnventura commentedIt'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.
Comment #4
pbfleetwood CreditAttribution: pbfleetwood commentedThanks so much for your quick response and explanation.
Comment #5
jcnventura CreditAttribution: jcnventura commentedActually, 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...
Comment #6
pbfleetwood CreditAttribution: pbfleetwood commentedI 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.
Without Close window after sending to printer
OR
With Close window after sending to printer
Without Close window after sending to printer
With Close window after sending to printer
OR
Comment #7
jcnventura CreditAttribution: jcnventura commentedOK. 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?
Comment #8
pbfleetwood CreditAttribution: pbfleetwood commentedYes, 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. :(
Comment #9
jcnventura CreditAttribution: jcnventura commentedOh, 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.
Comment #10
pbfleetwood CreditAttribution: pbfleetwood commentedMy 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 :)
Comment #11
pbfleetwood CreditAttribution: pbfleetwood commentedSo 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. (._.)
Comment #12
jcnventura CreditAttribution: jcnventura commentedThanks for your efforts, they're appreciated.
Comment #13
jcnventura CreditAttribution: jcnventura commentedI 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).
Comment #14
pbfleetwood CreditAttribution: pbfleetwood commentedThank you very much. I'm looking forward to trying out the new dev version as soon as time allows. :)
Comment #16
shaisamuel CreditAttribution: shaisamuel commentedI 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:
Comment #17
Vako CreditAttribution: Vako commentedI'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.
Comment #18
bisonbleu CreditAttribution: bisonbleu commentedI have similar issue as in #16
Open PDF in new browser window does not work i.e. PDF is opened in the same window.