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

RESOLVED FIXED in mozilla1.8.1

Status

()

Core
Printing: Output
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: (not reading, please use seth@sspitzer.org instead), Assigned: (not reading, please use seth@sspitzer.org instead))

Tracking

({fixed1.8.0.7, fixed1.8.1, regression})

1.8 Branch
mozilla1.8.1
x86
Windows XP
fixed1.8.0.7, fixed1.8.1, regression
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8.1 +
blocking1.8.0.7 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fixed on trunk, 1.8.1 branch, and 1.8.0 branch], URL)

Attachments

(4 attachments, 1 obsolete attachment)

[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.  
Created attachment 226676 [details]
groups printout
Created attachment 226677 [details]
maps printout
Summary: [printing] printing (a google pages) shows the style tag on paper (but → [printing] printing certain urls (google groups and maps) shows the style tag on paper (but not in preview)
here is the tag that is leaking:

<noscript><style type="text/css"><!--
.noscripthide { display:none; }
.noscriptinline { display:inline; }
.noscriptblock { display:block; }
//--></style></noscript>
Created attachment 226678 [details]
same thing, but on IE (no style tag leakage)
See also (at least until it turned trainwreck) bug 334944
Assignee: nobody → printing
Component: General → Printing
Product: Firefox → Core
QA Contact: general
Summary: [printing] printing certain urls (google groups and maps) shows the style tag on paper (but not in preview) → printing certain urls (google groups and maps) shows the style tag on paper (but not in preview)
Version: 2.0 Branch → 1.8 Branch
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.
Depends on: 334944, 340119
Summary: printing certain urls (google groups and maps) shows the style tag on paper (but not in preview) → printing certain urls (google groups and maps) from print preview shows the style/meta tags on paper
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..
Flags: blocking1.9a1?
Flags: blocking1.8.1?
Flags: blocking1.8.0.6?
> 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?

Updated

11 years ago
Flags: blocking1.8.1? → blocking1.8.1+
Created attachment 230074 [details] [diff] [review]
patch suggested by bz
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.
Assignee: printing → sspitzer
Target Milestone: --- → mozilla1.8.1
Attachment #230074 - Flags: review?(roc)
Status: NEW → ASSIGNED
Keywords: regression
Whiteboard: [fix in hand]
Whiteboard: [fix in hand] → [fix in hand, awaiting reviews]
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.
Attachment #230074 - Flags: review?(dbaron)
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.)
Attachment #230074 - Flags: superreview+
Attachment #230074 - Flags: review?(dbaron)
Attachment #230074 - Flags: review+
Created attachment 230525 [details] [diff] [review]
patch suggested by bz (with a comment, per dbaron)
Attachment #230074 - Attachment is obsolete: true
Attachment #230525 - Flags: superreview+
Attachment #230525 - Flags: review+
Attachment #230525 - Flags: approval1.8.1?
Attachment #230074 - Flags: review?(roc)
Attachment #230525 - Flags: approval1.8.0.6?
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

11 years ago
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.
Attachment #230525 - Flags: approval1.8.1? → approval1.8.1+
fixed on 1.8 branch, too.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Whiteboard: [fix in hand, awaiting reviews] → [fixed on 1.8 branch and trunk, bz wanted me to seek approval for 1.8.0.6, too]
Keywords: fixed1.8.1
Whiteboard: [fixed on 1.8 branch and trunk, bz wanted me to seek approval for 1.8.0.6, too] → [fixed on 1.8.1 branch and trunk, bz wanted me to seek approval for 1.8.0.6, 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
Flags: blocking1.8.0.7? → blocking1.8.0.7-
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
Attachment #230525 - Flags: approval1.8.0.7? → approval1.8.0.7+
I've checked in the fix to the 1.8.0 branch for 1.8.0.7.

thanks again to bz for the fix.
Keywords: fixed1.8.0.7
Whiteboard: [fixed on 1.8.1 branch and trunk, bz wanted me to seek approval for 1.8.0.6, too] → [fixed on trunk, 1.8.1 branch, and 1.8.0 branch]
Flags: blocking1.9a1?
You need to log in before you can comment on or make changes to this bug.