ot javascript question

  • Thread starter Thread starter e
  • Start date Start date
E

e

I've been having an extremely difficult time finding an answer to this in IE
/ js groups, so I thought I'd try here.

I've got an aspx page that delivers loads of report data into custom-named
<span> tags on the client, hidden from the screen by @media classes. From a
dynamically built menu of what was returned, the user selects wich report
they want to view/print and a little jscript .innerHTML magic happens under
the hood that copies the appropriate pages from the main report data into
another tag that they can see & print, it's been assigned a different @media
class. Subsequently they want to print it, so they hit the on-screen print
icon I provide for them, which simply performs a windows.print().
Everything works great up until that point; windows.print() just does
absolutely nothing. Not even an error. I did a general windows.print() test
on a dummy html page and the print dialog came up fine, so I suspect this
all has something to do with all the .innerHTML shifting I'm doing under the
hood? I have no idea, the lack of documentation for windows.print is diving
me insane, and I can't find anyone talking about a similar problem. Anyone
encountered this before?
 
What happens when you try to print via IE instead of your print button? If
it prints OK, check to see if you have an element named "print" on your
page. I remember encountering interesting problems with this a couple of
years ago, although I can't remember which browser(s) were affected or
exactly how the problem manifested. I do, however, remember that it took
forever to find the problem, which makes me suspect I wasn't seeing any
javascript errors either.

HTH,
Nicole
 
Using IE's file->print menu produces a correct result; the print dialog
comes up, and it only prints the corresponding @media areas that are
supposed to print - it does exactly what I want. And for what it's worth,
file->Print preview looks good too. I don't have any elements named
'print'... I have one called 'toPrint'... but that's as close as it comes.

MSDN's comment on window.print() is that it's synonymous to the user
selecting file->print, so; given file->print is working and window.print()
is not, I'm just plain stumped and confused at this point.
 
The problem almost certainly doesn't lie with window.print() if you can
actually print this via IE. There's something in your page
html/css/javascript that is causing window.print() to not execute correctly.
Unless you're willing to post a sample of the page that isn't working,
you'll probably need to resort to debugging this in little steps. Working
against a copy of the generated html page, take something out, see if it
works, take something else out, test again, etc...
 
I'll post a sample from the office monday. Here's something interesting I
found though, in the meantime on my laptop at home, just using winxp pro,
ie6 and notepad:

<html><body><head><title>test js page</title>
<script language=javascript>
function myTest()
{
newWin = window.open('', 'newwindow');
newWin.document.write('Hello');
newWin.print();
}
</script></head>
<body>
<a href="javascript: myTest()">test it</a>
</body>
</html>

The above sample will recreate my problem. You can comment/remove the
document.write line to have the .print method fire correctly. I don't know
if this is an "undocumented feature", a bug, or what. Now this is a bit of
a misleading experiment in that I'm not ever actually using document.write
in my application at work; it's all .innerHTML changes in that case. Never
the less, this sample reproduces the "silent-failure" of the print method
I'm encountering, so I suspect whatever is 'breaking' the print method in
this scenario is related to my problem at work.
 
Um... <html><body><head>... Interesting. <g>

There does seem to be a problem with window.print after using
document.write, at least on an empty page. That said, there is no similar
problem when using innerHTML on the body element. Try testing with the page
below:

<html>
<head>
<title>Printing tests</title>

<script language=javascript>
<!--
function testPrint(testType, doInnerHTML, doDocumentWrite)
{
var url;

switch (testType)
{
case 1:
{
url = window.location.href;
break;
}
case 2:
{
url = 'http://www.microsoft.com/';
break;
}
case 3:
{
url = '';
break;
}
}

var newWin = window.open(url, 'newwindow',
'width=300,height=300');

if (doInnerHTML)
{
newWin.document.body.innerHTML = 'innerHTML';

window.alert(newWin.document.documentElement.outerHTML);
}

if (doDocumentWrite)
{
newWin.document.write('document.write');

window.alert(newWin.document.documentElement.outerHTML);
}

window.alert('Click OK to try printing');
try
{
newWin.focus();
newWin.print();
}
catch (e)
{
window.alert(e.description);
}

newWin.close();
window.focus();
}

//-->
</script>

</head>
<body>
<a href="javascript: testPrint(1);">Test on site</a>
<br>
<a href="javascript: testPrint(2);">Test XSS</a>
<br>
<a href="javascript: testPrint(3);">Test empty URL</a>
<br>
<a href="javascript: testPrint(3, true);">Test empty URL with innerHTML</a>
<br>
<a href="javascript: testPrint(3, false, true);">Test empty URL with
document.write</a>
</body>
</html>
 
Nicole Calinoiu said:
Um... <html><body><head>... Interesting. <g>

woops :p
There does seem to be a problem with window.print after using
document.write, at least on an empty page. That said, there is no similar
problem when using innerHTML on the body element.

One of the things I tried before was to spawn a new window, body.innerHTML
some text and .print(), which actually did work; sort of. An issue with CSS
arose: the browser doesn't seem to cascade style data when it's supplied via
body.innerHTML to a new window. I tried <link> & <style> as part of the
..innerHTML text, but neither did the trick - the data in the new window was
not affected by the style information. And unfortunately, I need those
styles to be applied, esp. the @media ones. The only way I could get the
styles applied in the new window was to document.write, and that of course
put me right back at square 1 ( and lead me to discover that document.write
issue in my previous post ).
 
Well, the document.write -> no window.print thing does seem to something of
a bug. Why don't you circumvent it by using a saved html page as the
"blank" page, with the CSS link or style attribute pre-applied? This would
circumvent the need for using document.write and, hopefully, resolved the
printing problem.

HTH,
Nicole
 
Back
Top