Closed Bug 334944 Opened 18 years ago Closed 18 years ago

[FIX]Firefox printing content of <noscript> tag


(Core :: Printing: Output, defect, P1)






(Reporter: tomas, Assigned: bzbarsky)




(4 keywords)


(3 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; cs; rv: Gecko/20060308 Firefox/
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; cs; rv: Gecko/20060308 Firefox/

When I use "print" or "print preview" of menu, Firefox printing content of NOSCRIPT tag on paper (or on screen if I use "print previw"). This problem no exist in version 1.5.

Reproducible: Always

Steps to Reproduce:
1. open page which contains NOSCRIPT tag
2. use "print" or "print preview"
3. displaying or printing content od NOSCRIPT tag on paper or screen
Attached file testcase
This regressed on trunk between 2006-02-07 and 2006-02-10.
Since this regressed also on branch, so maybe this is a regression from bug 325991?

I'm not really sure, this is per se, when I look at some random specs:
"Scripts, as programs that are executed in conjunction with a document, are not relevant to the printed page. However, documents can provide information as an alternative to a script. Therefore, the script module is part of XHTML-Print since the content of the script element MUST be treated as if its display property were set to the value "none" and the content of the noscript element printed."

Also this might be relevant:

Opera9 and IE6 both don't show the extra text on print preview.

But anyway, since this behavior changed between 1.8 and, this is certainly a bug on branch at least.
Assignee: nobody → printing
Component: General → Printing
Ever confirmed: true
Keywords: regression, testcase
OS: Linux → All
Product: Firefox → Core
QA Contact: general
Version: unspecified → Trunk
So the problem here is that print preview and printing disable scripts in the document.  The presshell's preference stylesheet checks whether scripting is enabled when it's created and affects the rendering of <noscript> appropriately.

Now before bug 325991 landed, nsIDocument::IsScriptEnabled returned true for documents being printed (assuming script wasn't disabled in general).  That patch made it return false, since some scripts were checking the value to decide whether to run...

I suppose we could change the checks XBL does and back out the change to nsScriptSecurityManager::CanExecuteScripts that I made in bug 325991, but that seems unfortunate.  I'll try to think of something else we can do here.  :(
Blocks: 325991
Flags: blocking1.8.0.3?
So... I don't see this problem when printing.  I do see it in print preview, and will attach a patch that fixes that.

Are the people seeing this in printing just printing?  Or printing from inside print preview?
Attached patch Evil hack Splinter Review
I don't really see a better way to do this without changing APIs (and even then it'd just change where we store the state).
Assignee: printing → bzbarsky
Attachment #219314 - Flags: superreview?(dbaron)
Attachment #219314 - Flags: review?(dbaron)
Priority: -- → P1
Summary: Firefox printing content of <noscript> tag → [FIX]Firefox printing content of <noscript> tag
Target Milestone: --- → mozilla1.9alpha
Comment on attachment 219314 [details] [diff] [review]
Evil hack 

On the branch I'll change nsLayoutAtomList, of course.
Attachment #219314 - Flags: approval1.8.0.3?
Attachment #219314 - Flags: approval-branch-1.8.1?(dbaron)
(In reply to comment #4)
> Are the people seeing this in printing just printing?  Or printing from inside
> print preview?
I haven't tested printing, only print preview. Tomas, you're seeing this in printing?

This is not a critical bug.  Please get it reviewed and landed by Monday so it gets some bake time before code freeze.  If not, we'll need to push this out to
Comment on attachment 219314 [details] [diff] [review]
Evil hack 

Attachment #219314 - Flags: superreview?(dbaron)
Attachment #219314 - Flags: superreview+
Attachment #219314 - Flags: review?(dbaron)
Attachment #219314 - Flags: review+
Fixed on trunk.
Closed: 18 years ago
Resolution: --- → FIXED
*** Bug 335139 has been marked as a duplicate of this bug. ***
Flags: blocking1.8.0.3? → blocking1.8.0.3+
Comment on attachment 219314 [details] [diff] [review]
Evil hack 

approved for 1.8.0 branch, a=dveditz for drivers
Attachment #219314 - Flags: approval1.8.0.3? → approval1.8.0.3+
Attachment #219314 - Flags: approval-branch-1.8.1?(dbaron) → approval-branch-1.8.1?(roc)
Attached patch Merged to 1.8Splinter Review
Fixed on 1.8.0 branch.
Keywords: fixed1.8.0.3
Attachment #219314 - Flags: approval-branch-1.8.1?(roc) → approval-branch-1.8.1+
Fixed 1.8.1
Keywords: fixed1.8.1
Ummm... this is making the print/print preview of many, many sites look like **** right now, and this isn't critical?  That earlier statement floored me.
Steve, a critical bug for a stable branch would be one that allowed a website to take over your computer.  This bug is annoying, yes.  But not at all critical.
(In reply to comment #17)
> Steve, a critical bug for a stable branch would be one that allowed a website
> to take over your computer.  This bug is annoying, yes.  But not at all
> critical.

I can't speak for my customer (Major Airline), but getting an airline boarding pass via a web self-checkin application with verbatim HTML in it is more than an annoyance.  It's a brand image problem, it's a customer confidence problem, and worse, it's not even *our* problem.  I'd get that puppy fixed and propped if I were you.  There's a big picture out there Boris, and you're just not seeing it.
(In reply to comment #18)
> (In reply to comment #17)
> > Steve, a critical bug for a stable branch would be one that allowed a website
> > to take over your computer.  This bug is annoying, yes.  But not at all
> > critical.
> > 

My apologies for the snarky reply; Boris had already responded comprehensively to an e-mail query (which I hadn't yet seen) and it's all good for now.

Appears to be partially fixed (that is, still not really fixed) in Firefox v1.5.0.4.

Upon launching Print Preview, the view that was showing the NOSCRIPT content now displays the page normally.

But, then, I tried something.  I switched to a landscape view, away from portrait.  Voila!  The original problem of NOSCRIPT content being displayed returned.

This also happens if I change the scale.
Steve, could you please file a separate bug, with steps to reproduce?  We're going to have to find someone to fix it, since none of the operations you describe are available on Linux so I can't debug it.  :(
I would prefer not to file a separate bug.  This is because in normal software development practice, this bug would be reopened, as the fix turned out to not be a fix.  I will not act against normal software development practice--of course, that won't stop somebody else from doing it.
In normal Mozilla development practice, there's one bug per issue.  Different steps to reproduce generally mean different issues, esp. if one can be fixed without fixing the others...  This is not to say one shouldn't try to fix them all at once.  ;)
Yes, one bug per issue.  And the bug reported in this issue wasn't fixed.

I don't agree with the suggestion that what I'm reporting as a partial fix to this issue constitutes a separate bug/issue.  And I cannot be a party to pretending that this bug was diligently handled and move on.  Any reasonable developer would say this bug was not actually fixed.

Further, I've already essentially outlined the steps to reproduce (i.e., it's simple).  1) Do print preview of a site containing a NOSCRIPT (looks fine); 2) Change to landscape mode (if in portrait mode), or change to portrait mode (if in landscape mode) -- Voila.
Steve, in case you missed it, I fixed all parts of this bug I could reproduce...  If someone had mentioned that there were other issues too, I would have tried to fix them as well, or looked for someone else to do so, but no one bothered to mention them.

The fact of the matter is, print preview behaves very differently on the different operating systems we support; the <noscript> issue that appeared on all is fixed and the one that only appears on some needs investigation as to _why_ it appears.  I've filed bug 340119 for said investigation.
That's fine that you fixed all the aspects you could reproduce.  I'm not interested in saying a developer is bad because they missed something.  This is just a matter of development integrity.

If a bug isn't fully fixed, it shouldn't be closed.  This happens in development sometimes.  A developer who works on fixing a bug has a responsibility to explore the full gamut of scenarios surrounding a reported bug, even including scenarios not exactly reported.

Who would it hurt to reopen this bug?  It's not like you would be fired for doing so.  Right?
> Who would it hurt to reopen this bug? 

The QA folks who are tracking what's fixed where and when.
So, QA will track this bug as fixed even though it's not fixed?  mmmm-k.  Moving on...
QA will track a specific issue as fixed, even though other related issues are not fixed.
Again, it's not a case of "related issues not being fixed".  It's a case of *this* specific bug not being fully fixed.
The definition of a bug in this project is based on code-level issues, not user-experience issues. And i'd think that boris will be a better judge than most on that one.

Some of the time we even open a new bug when a bug has become so full of unrelated information, which by now this one has.

So please, if you have further issues, please open a new bug.
*** Bug 338592 has been marked as a duplicate of this bug. ***
This *is* a code-level issue that's not fully resolved, says this software developer of 16+ years.  I am absolutely confident of my position.  So, this will just be a disagreement that never ends.  However, I'd be happy to let this dog lie if people would stop making absurdist statements that I find I must answer.  :) 

Further, the new issue covering the "related issues" was already opened.
So I just checked in the fix for bug 340119 on the 1.8.0 branch.  It would be wonderful if someone who can test tomorrow's branch nightlies on Mac and Windows would do so and let me know how things look.
Unfortunately, there are two reports that printing is still messed up in Fx, although the print preview is fine.  The reports appear credible, although I cannot duplicate in this version.

Do you want to reopen, refile, or wait and see?
Isn't that bug 342439?
I'm not sure.  It might be close.  Someone did finally post a problem I can reproduce:

If JavaScript is enabled it prints tags from .  The problem is, it only happens with JS enabled.  What do you think?
If you're printing from inside print preview, that's bug 342439.
You need to log in before you can comment on or make changes to this bug.