[printing] printing (a google pages) shows the style tag on paper (but not in preview) try it with http://groups.google.com/group/mozilla.dev.apps.firefox/msg/46e9754733d4a436 I have seen this on google maps, too. I'll get a test case see attached pdf. I'm using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060620 BonEcho/2.0a3

yes, print this: http://maps.google.com/maps?oi=map&q=51+Campbell+Avenue,+Campbell,+CA I am using http://www.pdf995.com/ to print to pdf on windows. here come two pdfs.

here is the tag that is leaking: <noscript><style type="text/css"><!-- .noscripthide { display:none; } .noscriptinline { display:inline; } .noscriptblock { display:block; } //--></style></noscript>

See also (at least until it turned trainwreck) bug 334944

thanks for the bug links, phil. for test case, use http://maps.google.com/maps?oi=map&q=51+E+Campbell+Avenue,+Campbell,+CA (instead of my link in comment #1). bz, this seems related to bugs #334944 and #340119. Note, I've tried a recent trunk build (and recent branch build) on windows, and this issue remains. updating summary. to answer bug #334944 comment #4 > Are the people seeing this in printing just printing? Or printing from inside > print preview? yes, I only see this with print preview. print works fine.

So it doesn't appear in print preview, but does when you print from print preview? If so, I'll need some help debugging here, since on Linux printing from inside print preview is impossible..

> So it doesn't appear in print preview, but does when you print from print > preview? yes, that is what I'm seeing. > If so, I'll need some help debugging here, since on Linux printing from inside > print preview is impossible.. I've got a debug win32 build, so I should be able to help you out. Any suggestions on where to start looking?

I'd probably start by breakpointing in TurnScriptingOn and seeing what it's called with... After the first time we've disabled scripting, breakpoint in PresShell::SetPrefNoScriptRule and see what happens there?

thanks again to bz for working with me over irc and for suggesting a fix. I'll seek approval for 1.8.0x, 1.8 and trunk. bz suggested that roc r+sr this bug.

Comment on attachment 230074 [details] [diff] [review] patch suggested by bz maybe dbaron can review? I'd like to get this into the branch for 2.0b2, too.

Comment on attachment 230074 [details] [diff] [review] patch suggested by bz r+sr=dbaron, although you might want to add a comment that you're checking print for the case where printing is done from the print preview window. (Although I wonder if what we should really be doing is checking mDocument->GetShellAt(0)->GetPresContext()->Type == nsPresContext::eContext_PrintPreview . Except that might break if we made print preview work sensibly, although doing that would probably lead to tearing all this code out anyway.)

Comment on attachment 230525 [details] [diff] [review] patch suggested by bz (with a comment, per dbaron) note, I fixed this typo: "// see bug #242439 for more details" "// see bug #342439 for more details

Your editor let you insert a tab. Bad editor!

Comment on attachment 230525 [details] [diff] [review] patch suggested by bz (with a comment, per dbaron) a=drivers. Please land on the MOZILLA_1_8_BRANCH.

fixed on 1.8 branch, too.

I've verified that 1.5.0.x has this bug, and that applying this to the MOZILLA_1_8_0_BRANCH fixes it. Is this worth taking for 1.5.0.6?

> Is this worth taking for 1.5.0.6? I see that it is in the pipeline for the 1.8.0.7 (1.5.0.7) release and not the 1.8.0.6 release (1.5.0.6). I'll wait for drivers to process the nomination.

Yeah, 1.8.0.6 is basically 1.8.0.5 with a major snafu fixed. This should go into 1.8.0.7...

Not blocking 1.8.0.x but we'll look at the patch

Comment on attachment 230525 [details] [diff] [review] patch suggested by bz (with a comment, per dbaron) approved for 1.8.0 branch, a=dveditz for drivers

I've checked in the fix to the 1.8.0 branch for 1.8.0.7. thanks again to bz for the fix.