342439 - printing certain urls (google groups and maps) from print preview shows the style/meta tags on paper

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[(not reading, please use [e-mail] instead)]

[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

Comment 1

[(not reading, please use [e-mail] instead)]

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.  

Comment 2

[(not reading, please use [e-mail] instead)]

Attachment: groups printout

Comment 3

[(not reading, please use [e-mail] instead)]

Attachment: maps printout

Comment 4

[(not reading, please use [e-mail] instead)]

here is the tag that is leaking:

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

Comment 5

[(not reading, please use [e-mail] instead)]

Attachment: same thing, but on IE (no style tag leakage)

Comment 6

[Phil Ringnalda (:philor)]

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

Comment 7

[(not reading, please use [e-mail] instead)]

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.

Comment 8

[Boris Zbarsky [:bzbarsky]]

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..

Comment 9

[(not reading, please use [e-mail] instead)]

> 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?

Comment 10

[Boris Zbarsky [:bzbarsky]]

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?

Comment 11

[(not reading, please use [e-mail] instead)]

Attachment: patch suggested by bz

Comment 12

[(not reading, please use [e-mail] instead)]

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 13

[(not reading, please use [e-mail] instead)]

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 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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 15

[(not reading, please use [e-mail] instead)]

Attachment: patch suggested by bz (with a comment, per dbaron)

Comment 16

[(not reading, please use [e-mail] instead)]

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

Comment 17

[jag (Peter Annema)]

Your editor let you insert a tab. Bad editor!

Comment 18

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 19

[(not reading, please use [e-mail] instead)]

fixed on 1.8 branch, too.

Comment 20

[(not reading, please use [e-mail] instead)]

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?

Comment 21

[(not reading, please use [e-mail] instead)]

> 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.

Comment 22

[Boris Zbarsky [:bzbarsky]]

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

Comment 23

[Daniel Veditz [:dveditz]]

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

Comment 24

[Daniel Veditz [:dveditz]]

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

Comment 25

[(not reading, please use [e-mail] instead)]

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

thanks again to bz for the fix.