Active
Project:
Printer, email and PDF versions
Version:
7.x-1.x-dev
Component:
Miscellaneous
Priority:
Major
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
15 May 2012 at 12:24 UTC
Updated:
9 May 2016 at 19:38 UTC
Jump to comment: Most recent
Comments
Comment #1
jcnventuraAre 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 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
jcnventuraIt'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 commentedThanks so much for your quick response and explanation.
Comment #5
jcnventuraActually, 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 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
jcnventuraOK. 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 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
jcnventuraOh, 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 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 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
jcnventuraThanks for your efforts, they're appreciated.
Comment #13
jcnventuraI 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 commentedThank you very much. I'm looking forward to trying out the new dev version as soon as time allows. :)
Comment #16
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 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 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.