Last Comment Bug 334944 - [FIX]Firefox printing content of <noscript> tag
: [FIX]Firefox printing content of <noscript> tag
Status: RESOLVED FIXED
: fixed1.8.0.4, fixed1.8.1, regression, testcase
Product: Core
Classification: Components
Component: Printing: Output (show other bugs)
: Trunk
: x86 All
: P1 normal (vote)
: mozilla1.9alpha1
Assigned To: Boris Zbarsky [:bz] (still a bit busy)
:
:
Mentors:
http://www.woko.cz/akce.phtml?ukaz=uvod
: 335139 338592 (view as bug list)
Depends on:
Blocks: 325991 342439
  Show dependency treegraph
 
Reported: 2006-04-21 05:35 PDT by Tomas Krause
Modified: 2006-08-03 09:31 PDT (History)
9 users (show)
dveditz: blocking1.8.0.4+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (229 bytes, text/html)
2006-04-21 06:05 PDT, Martijn Wargers [:mwargers] (not working for Mozilla)
no flags Details
Evil hack (3.90 KB, patch)
2006-04-21 09:49 PDT, Boris Zbarsky [:bz] (still a bit busy)
jst: review+
jst: superreview+
roc: approval‑branch‑1.8.1+
dveditz: approval1.8.0.4+
Details | Diff | Splinter Review
Merged to 1.8 (4.16 KB, patch)
2006-04-24 12:21 PDT, Boris Zbarsky [:bz] (still a bit busy)
no flags Details | Diff | Splinter Review

Description Tomas Krause 2006-04-21 05:35:21 PDT
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 [:mwargers] (not working for Mozilla) 2006-04-21 06:05:12 PDT
Created attachment 219297 [details]
testcase
Comment 2 Martijn Wargers [:mwargers] (not working for Mozilla) 2006-04-21 06:11:25 PDT
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 [:bz] (still a bit busy) 2006-04-21 09:02:11 PDT
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 [:bz] (still a bit busy) 2006-04-21 09:48:59 PDT
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 [:bz] (still a bit busy) 2006-04-21 09:49:47 PDT
Created attachment 219314 [details] [diff] [review]
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 [:bz] (still a bit busy) 2006-04-21 09:51:10 PDT
Comment on attachment 219314 [details] [diff] [review]
Evil hack 

On the branch I'll change nsLayoutAtomList, of course.
Comment 7 Martijn Wargers [:mwargers] (not working for Mozilla) 2006-04-21 09:53:58 PDT
(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] 2006-04-21 12:02:34 PDT
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, jst@mozilla.com) 2006-04-21 17:03:22 PDT
Comment on attachment 219314 [details] [diff] [review]
Evil hack 

r+sr=jst
Comment 10 Boris Zbarsky [:bz] (still a bit busy) 2006-04-21 17:08:48 PDT
Fixed on trunk.
Comment 11 Frank Wein [:mcsmurf] 2006-04-23 04:11:51 PDT
*** Bug 335139 has been marked as a duplicate of this bug. ***
Comment 12 Daniel Veditz [:dveditz] 2006-04-24 11:52:22 PDT
Comment on attachment 219314 [details] [diff] [review]
Evil hack 

approved for 1.8.0 branch, a=dveditz for drivers
Comment 13 Boris Zbarsky [:bz] (still a bit busy) 2006-04-24 12:21:58 PDT
Created attachment 219633 [details] [diff] [review]
Merged to 1.8
Comment 14 Boris Zbarsky [:bz] (still a bit busy) 2006-04-24 12:28:42 PDT
Fixed on 1.8.0 branch.
Comment 15 Boris Zbarsky [:bz] (still a bit busy) 2006-04-27 16:14:44 PDT
Fixed 1.8.1
Comment 16 Steve Magruder 2006-04-28 09:10:29 PDT
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 [:bz] (still a bit busy) 2006-04-28 09:18:45 PDT
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 2006-06-01 14:49:04 PDT
(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 2006-06-01 14:54:23 PDT
(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 2006-06-01 23:58:52 PDT
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 [:bz] (still a bit busy) 2006-06-02 08:32:02 PDT
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 2006-06-02 08:46:03 PDT
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 [:bz] (still a bit busy) 2006-06-02 08:54:07 PDT
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 2006-06-02 09:04:04 PDT
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 [:bz] (still a bit busy) 2006-06-02 09:18:43 PDT
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 2006-06-02 09:27:25 PDT
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 [:bz] (still a bit busy) 2006-06-02 09:29:30 PDT
> Who would it hurt to reopen this bug? 

The QA folks who are tracking what's fixed where and when.
Comment 28 Steve Magruder 2006-06-02 09:44:46 PDT
So, QA will track this bug as fixed even though it's not fixed?  mmmm-k.  Moving on...
Comment 29 Boris Zbarsky [:bz] (still a bit busy) 2006-06-02 10:00:19 PDT
QA will track a specific issue as fixed, even though other related issues are not fixed.
Comment 30 Steve Magruder 2006-06-02 10:05:42 PDT
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 2006-06-02 11:08:41 PDT
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 jonmorrow 2006-06-02 11:15:03 PDT
*** Bug 338592 has been marked as a duplicate of this bug. ***
Comment 33 Steve Magruder 2006-06-02 11:24:59 PDT
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 [:bz] (still a bit busy) 2006-06-06 16:27:07 PDT
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 2006-08-02 21:49:50 PDT
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 [:bz] (still a bit busy) 2006-08-02 22:14:24 PDT
Isn't that bug 342439?
Comment 37 VanillaMozilla 2006-08-03 09:19:24 PDT
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 [:bz] (still a bit busy) 2006-08-03 09:31:46 PDT
If you're printing from inside print preview, that's bug 342439.

Note You need to log in before you can comment on or make changes to this bug.