Clicking the print button in IE 8 does nothing at all. Works fine for me in Firefox and Chrome.

- Jim

Comments

pha3z’s picture

pha3z commented

Here's why:

'console is undefined'

The line from the javascript file is: console.log(settings);

IE 8 doesn't know what console is.

Deleting that line will allow the javascript to run and load the window. However there's ANOTHER bug. The new window loads like a regular page. The elements you don't want to print are still visible. Also, the print command doesn't execute. So it appears that when the new window loads, the onload function is not getting attached and executed.

pha3z’s picture

pha3z commented

Did some digging around and I found this link where someone was complaining about the onload event not firing for new windows in IE 8. Its a slightly different setup so I'm not sure if the issue is the same but it might be. I'm not a javascript guru so I don't know how to fix or workaround this off hand.

http://stackoverflow.com/questions/5420828/javascript-ie8-window-onload-is-not-working-in-new-opened-window

pha3z’s picture

pha3z commented

I think this is the solution:

http://stackoverflow.com/questions/4961728/how-to-open-a-new-window-with-generated-javascript-code

A solution to the problem is discussed, but one of the commenters made this point:
Why write to the new window? Why don't you just pass the information needed as querystring parameters and have the new page build the document.

I think that's a good point. a GET variable could be added to the URI with the ID for the target element to print. Area Print javascript on teh new page could recognize it and react by realizing this is the print page and it needs to go ahead and hide all other elements and call the print method.

bfr’s picture

bfr commented

Thanks, i'll look into this. The issue in #1 is already fixed in the dev. As for the solution in #3, i think i started off like that but browser randomly tried to open the print window before the actual content was rendered, ending up with empty print window. I'll try to debug with IE 8, it's just little problematic since i dont have any windows machines :(. I'll try to figure out solution, meanwhile, patches are welcome.

EDIT:
Actually, i red your comment better, the module already is working like you suggested. Back to debugging :(

bfr’s picture

bfr commented
Status: Active » Needs review

So, as always, the problem is that IE does not respect any standards. IE was not waiting for the page to load when onload event occured.

The solution is bit dirty, but best i could come up with now. When using IE, an alert box appears that says "Press OK to print". That should give IE enough
time to load the page.

Please try if the solution works for you(either take the latest version from git or wait for the 7.x-1.x package to update). If it does, i'll release
another stable.

Better solutions are welcome also.

pha3z’s picture

pha3z commented

How about deferring the javascript parsing? You might be able to get rid of the onload event and just use procedural code that is deferred until after the DOM is ready. This might produce different behavior on various browsers, but its worth a shot.

bfr’s picture

bfr commented

Would that not require modernizr , LABJS or some other external library? Would it not be overkill just for getting this simple functinality work better on a single browser? Another solution could be to use to use async tag, but i dont think we are ready for HTML5-only yet.

pha3z’s picture

pha3z commented

none of the pages that talk about defer javascript or defer parsing mention some kind of additional module. Its native to core javascript.

- Jim

pha3z’s picture

pha3z commented

We really need to get this working because of limitations in the regular Print module. I may have to devote more time to making Area Print work in IE. bfr, are you having any luck?

pha3z’s picture

pha3z commented

From here: http://bytes.com/topic/javascript/answers/582360-opening-new-window-attaching-onload-event-listener
"When you open your popup, it contains an empty document. You attach an
onload handler to the empty document, then re-direct the URL so that
document is destroyed and a new one is loaded.

You have to put the onload handler in the new document, you can't
attach it from the calling page unless you actually write the document
from the calling page (say using document.write)."

My opinion: Personally, I think this makes perfect sense. The behavior exhibited by Internet Explorer is the browser that's doing what it should do in this case. I think its actually weird that the other browsers are working.

Anyway, I'm going to test your dirty hack solution that uses a Press OK box. It'll get the job done well enough for now.

pha3z’s picture

pha3z commented

I could be crazy, but I think the latest developer version broke it in FireFox.

Its working in IE with the hack fix where you Press OK to print.

LOL

- Jim

bfr’s picture

bfr commented
Status: Needs work » Needs review

I think you are right, now other browser are having problems. If you are in hurry, Until we come up with real solution, we could either add the "ok" alert box to all browsers or add some artificial delay. I just dont like delays, since it's hard to say how long the delay should be. I like bulletproof, not guessing.

Edit:
Found out the reason it broke in firefox and chrome and got it fixed, i'll play a little more with IE before commiting if i'd happen to figure out something.

bfr’s picture

bfr commented
Status: Needs review » Needs work
bfr’s picture

bfr commented
Status: Needs review » Needs work

Firefox and Chrome are now working and also adding the custom css seemed to have broken at some point, that should be working now again.

pha3z’s picture

pha3z commented

Hmm. Did you upload the newest version? I just downloaded the latest developer build and it seems to be the same. Same behavior.

- Jim

bfr’s picture

bfr commented

It's commited but it takes some hours before drupal.org creates the new package(once a day?). Or you can pull it straight from the repository by visiting the version control tab on the project page.

Edit: Above just for the future reference, of course by now the package should already be updated.

pha3z’s picture

pha3z commented

I tested the May 14 package on Chrome, FF, and IE. It appears to be working! Good work! The alert box that requires the user to press OK is acceptable for my needs. I agree that it should be better streamlined, but that is not urgent. This will work.

Thanks for getting it fixed!!!!!!!!!!!!!!! :) Lots of hearts and smileys for you!!

bfr’s picture

bfr commented
Status: Needs work » Fixed

Ok, great, i'll mark this as fixed for now and trigger a stable release so people who dont use dev-versions get some working versions for IE. Let's figure a better solution later.

Status: Fixed » Closed (fixed)

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