66713 - Add UI to turn on/off print headers/footers

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, enhancement, P2)

Description

[Bill Law]

From a recent email:

>Rod Spears is about to checkin a patch to enable printing of headers and
>footers. Currently there isn't any UI to control whether the headers and
>footers are printed so they will always be printed. If you decide to add
>UI so headers and footers can be turned off  it can be done easily
>through the nsIPrintOptions object.

I'm not sure where that UI would go since there are not currently any xp print
dialogs (I don't think).  Needs investigation.

Comment 1

[Bill Law]

Making nsbeta1+ (milestone is mozilla0.9.1.

Comment 2

[Viswanath Ramachandran]

Yes lets add it in the preferences. We need to define a pref and expose it in
advanced > Printing (create this entry in the tree). Bij/German - does this
sound right?

Comment 3

[Viswanath Ramachandran]

Bill - to make nsbeta1, it has to be in mozilla0.9 or earlier. Can we get it 
then? We can cut another bug if you want. thanks, Vishy

Comment 4

[Bill Law]

Resetting target milestone.  Adding a new pref pane is doable (adding a whole
new xp print dialog was what had me worried).

Comment 5

[Matthew T (active 1999-2002)]

Headers and footers *in the prefs dialog*??? Excuse my language, but that's 
completely daft. Headers and footers are things users want to turn on and off for 
individual print jobs, not things they set in prefs in preparation for the print 
jobs they are going to perform in the future. If UI for them is not present in 
the `Print As ...' dialog, it might as well not be present at all.

Comment 6

[sairuh (rarely reading bugmail)]

over to sujay for print qa... not sure if this should go to printing or prefs
component; guessing the former. :)

Comment 7

[Kathleen :Brade]

Bill--if you can't do this bug for 0.9, please change the default of the prefs to 
be off.  This would be more compatible with Netscape6.  I had the misfortune of 
print a document in Netscape 6, making a few changes and then printing it with 
6.5 (and got headers much to my dismay since there is no way to turn them off).  
I'd hate to tell people to keep Netscape 6 around if they ever want to print 
without headers.  :-(

On another note, can this be incorporated into the "Page Setup"/"Print Setup" 
dialog?  (bugs #42817 and #36796)

Comment 8

[Bill Law]

Spam: new helper app dialog not making mozilla0.9, unfortunately.

Comment 9

[Viswanath Ramachandran]

as discussed in team meeting, moving all Nav+ team members nsbeta1+ P3 bugs from 
mozilla0.9.1 to mozilla0.9.2. 

Comment 10

[Paul Chen]

nav triage team:

Reassigning to vishy and marking mozilla0.9.3

Comment 11

[Paul Chen]

nav triage team:

Not a mozilla0.9.3 stopper, nice to have, but not a 0.9.3 stopper. Marking 
mozilla1.0

Comment 12

[Keyser Sose]

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

Comment 13

[Jatin Billimoria]

Is this proposed feature in or out for the 0.9.4 branch?

Comment 14

[sairuh (rarely reading bugmail)]

->trudelle for triage.

Comment 15

[Peter Trudelle]

->law, p2/enhancement for 0.9.6

Comment 16

[Marek Z. Jeziorek]

under assumption that this is just dealing with Netscape UI (and not with the
embedding APIs) removing topembed from the bug

Comment 17

[Bill Law]

Paul gets this one now.

Comment 18

[Simon Fraser [no longer active]]

See also bug 42817 which is about Page/Print setup.

Comment 19

[Paul Chen]

moving out to mozilla0.9.8

Comment 20

[Boris Zbarsky [:bzbarsky]]

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

Comment 21

[Daniel Brooks [:db48x]]

If only for my own purposes, I went ahead and added a panel to my prefs window
to control the header and footer. I'll go ahead and post the patch (a diff and a
new file not included in the diff because I can't add it to the tree.) This
could be checked in temporarily if need be, but I for one won't be upset if it's
not. It doesn't really belong in the prefs window. Have fun.

Comment 22

[Daniel Brooks [:db48x]]

Attachment: patch + new file

Comment 23

[Boris Zbarsky [:bzbarsky]]

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

Comment 24

[Boris Zbarsky [:bzbarsky]]

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

Comment 25

[Boris Zbarsky [:bzbarsky]]

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

Comment 26

[Peter Trudelle]

->law

Comment 27

[Bill Law]

UI is in place.  See bug 113727 for discussion of making it better.

Comment 28

[sujay]

verified. UI is in place in Page Setup.

Comment 29

[Kathleen :Brade]

reopening bug; how do I do this on a Macintosh?
I could do this in 4.x; this is a regression/parity issue.

Comment 30

[Andrew Hagen]

The UI for this should be in file | page setup.

If it's not working on the Mac, is that all that's left in this bug?

Comment 31

[Andrew Hagen]

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

Comment 32

[sujay]

changing OS to Mac...

Comment 33

[John Beck]

There is a File -> Page Setup (which works) on Unix and Windows; the Mac
version of this just brings up the system Page Setup which doesn't know
about these headers/footers.  On Unix, I added:

user_pref("print.print_headerleft", "");
user_pref("print.print_headercenter", "");
user_pref("print.print_headerright", "");
user_pref("print.print_footerleft", "");
user_pref("print.print_footercenter", "");
user_pref("print.print_footerright", "");

to my user.js and they were all blanked out as I desired.  But on
Mac OS X, this was a no-op.  (Using Mozilla 1.2.1 on all three OSs.

Comment 34

[Daryl Forrest]

I also tried setting the various "print.print_header*" both from the
about:config screen and directly by editing the user.js file, and these settings
were ignored. This was using Mozilla 1.3 under Mac OS X v10.2.4. This really
needs to be fixed.

Even if no GUI is added, can someone enable these "print.print_header*" settings
so they are honored and not simply ignored?

Comment 35

[Boris Zbarsky [:bzbarsky]]

Over to a more real owner....

Comment 36

[Jasper]

This is still an issue for Camino. See Bug 220201.
Could some one take a look at this again?

Comment 37

[Blake Ross]

Reassigning obsolete bugs to their respective Seamonkey owners (i.e. nobody). 
If you want this fixed for Firefox, change the Product and Component accordingly
and reassign back to me.

Comment 38

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Is this not a dupe of the recent work going on in bug 202014?  (Different
product, but the fix seems to be putting the header/footer UI in the
PrintPDE.plugin so all the Mac browsers can have it in one fell swoop?)

Comment 39

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Marking this fixed by virtue of bug 202014.  In any Moz Mac app, these settings
can be accessed in the "AppName" pane of the Print dialogue (i.e., click "Copies
and Pages" and scroll the list to the item that matches the name of the app
you're using).