334944 - [FIX]Firefox printing content of <noscript> tag

Status: RESOLVED FIXED

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

Description

[Tomas Krause]

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

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

Comment 1

[Martijn Wargers (dead)]

Attachment: testcase

Comment 2

[Martijn Wargers (dead)]

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:
http://www.w3.org/TR/xhtml-print/#s1.3.1
"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:
http://www.w3.org/TR/REC-html40/interact/scripts.html#h-18.3.1

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

But anyway, since this behavior changed between 1.8 and 1.8.0.2, this is certainly a bug on branch at least.

Comment 3

[Boris Zbarsky [:bzbarsky]]

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

Comment 4

[Boris Zbarsky [:bzbarsky]]

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?

Comment 5

[Boris Zbarsky [:bzbarsky]]

Attachment: Evil hack

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

Comment 6

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 219314 [details] [diff] [review]
Evil hack 

On the branch I'll change nsLayoutAtomList, of course.

Comment 7

[Martijn Wargers (dead)]

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

Comment 8

[Tim Riley [:timr]]

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

Comment 9

[Johnny Stenback (:jst)]

Comment on attachment 219314 [details] [diff] [review]
Evil hack 

r+sr=jst

Comment 10

[Boris Zbarsky [:bzbarsky]]

Fixed on trunk.

Comment 11

[Frank Wein [:mcsmurf]]

*** Bug 335139 has been marked as a duplicate of this bug. ***

Comment 12

[Daniel Veditz [:dveditz]]

Comment on attachment 219314 [details] [diff] [review]
Evil hack 

approved for 1.8.0 branch, a=dveditz for drivers

Comment 13

[Boris Zbarsky [:bzbarsky]]

Attachment: Merged to 1.8

Comment 14

[Boris Zbarsky [:bzbarsky]]

Fixed on 1.8.0 branch.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Fixed 1.8.1

Comment 16

[Steve Magruder]

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.

Comment 17

[Boris Zbarsky [:bzbarsky]]

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.

Comment 18

[Brook Monroe]

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

Comment 19

[Brook Monroe]

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

Comment 20

[Steve Magruder]

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.

Comment 21

[Boris Zbarsky [:bzbarsky]]

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

Comment 22

[Steve Magruder]

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.

Comment 23

[Boris Zbarsky [:bzbarsky]]

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

Comment 24

[Steve Magruder]

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.

Comment 25

[Boris Zbarsky [:bzbarsky]]

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.

Comment 26

[Steve Magruder]

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?

Comment 27

[Boris Zbarsky [:bzbarsky]]

> Who would it hurt to reopen this bug? 

The QA folks who are tracking what's fixed where and when.

Comment 28

[Steve Magruder]

So, QA will track this bug as fixed even though it's not fixed?  mmmm-k.  Moving on...

Comment 29

[Boris Zbarsky [:bzbarsky]]

QA will track a specific issue as fixed, even though other related issues are not fixed.

Comment 30

[Steve Magruder]

Again, it's not a case of "related issues not being fixed".  It's a case of *this* specific bug not being fully fixed.

Comment 31

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 32

[Jon]

*** Bug 338592 has been marked as a duplicate of this bug. ***

Comment 33

[Steve Magruder]

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.

Comment 34

[Boris Zbarsky [:bzbarsky]]

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.

Comment 35

[VanillaMozilla]

Unfortunately, there are two reports that printing is still messed up in Fx 1.5.0.5, although the print preview is fine.  The reports appear credible, although I cannot duplicate in this version.
http://forums.mozillazine.org/viewtopic.php?p=2404226#2404226

Do you want to reopen, refile, or wait and see?

Comment 36

[Boris Zbarsky [:bzbarsky]]

Isn't that bug 342439?

Comment 37

[VanillaMozilla]

I'm not sure.  It might be close.  Someone did finally post a problem I can reproduce:
http://forums.mozillazine.org/viewtopic.php?p=2409045#2409045

If JavaScript is enabled it prints tags from www.yahoo.com .  The problem is, it only happens with JS enabled.  What do you think?

Comment 38

[Boris Zbarsky [:bzbarsky]]

If you're printing from inside print preview, that's bug 342439.