Closed Bug 66713 Opened 24 years ago Closed 19 years ago

Add UI to turn on/off print headers/footers


(SeaMonkey :: UI Design, enhancement, P2)



(Not tracked)



(Reporter: law, Unassigned)




(1 file)

2.52 KB, application/x-zip-compressed
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.
Making nsbeta1+ (milestone is mozilla0.9.1.
Keywords: nsbeta1
Target Milestone: --- → mozilla0.9.1
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?
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
Priority: -- → P3
Resetting target milestone.  Adding a new pref pane is doable (adding a whole
new xp print dialog was what had me worried).
Target Milestone: mozilla0.9.1 → mozilla0.9
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.
over to sujay for print qa... not sure if this should go to printing or prefs
component; guessing the former. :)
Component: XP Apps: GUI Features → Printing
QA Contact: sairuh → sujay
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)
Keywords: nsbeta1nsbeta1+
Spam: new helper app dialog not making mozilla0.9, unfortunately.
Target Milestone: mozilla0.9 → mozilla0.9.1
as discussed in team meeting, moving all Nav+ team members nsbeta1+ P3 bugs from 
mozilla0.9.1 to mozilla0.9.2. 
Target Milestone: mozilla0.9.1 → mozilla0.9.2
nav triage team:

Reassigning to vishy and marking mozilla0.9.3
Assignee: law → vishy
Target Milestone: mozilla0.9.2 → mozilla0.9.3
nav triage team:

Not a mozilla0.9.3 stopper, nice to have, but not a 0.9.3 stopper. Marking 
Target Milestone: mozilla0.9.3 → mozilla1.0
*** Bug 90120 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.0 → mozilla0.9.5
Is this proposed feature in or out for the 0.9.4 branch?
->trudelle for triage.
Assignee: vishy → trudelle
Depends on: 99415
->law, p2/enhancement for 0.9.6
Assignee: trudelle → law
Severity: normal → enhancement
Priority: P3 → P2
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Keywords: topembed
under assumption that this is just dealing with Netscape UI (and not with the
embedding APIs) removing topembed from the bug
Keywords: topembed
Paul gets this one now.
Assignee: law → pchen
See also bug 42817 which is about Page/Print setup.
moving out to mozilla0.9.8
Target Milestone: mozilla0.9.6 → mozilla0.9.8
*** Bug 107503 has been marked as a duplicate of this bug. ***
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.
Attached file patch + new file
Blocks: 69459
*** Bug 95239 has been marked as a duplicate of this bug. ***
*** Bug 113114 has been marked as a duplicate of this bug. ***
*** Bug 117368 has been marked as a duplicate of this bug. ***
Assignee: pchen → law
Target Milestone: mozilla0.9.8 → ---
UI is in place.  See bug 113727 for discussion of making it better.
Closed: 23 years ago
Resolution: --- → FIXED
verified. UI is in place in Page Setup.
reopening bug; how do I do this on a Macintosh?
I could do this in 4.x; this is a regression/parity issue.
Resolution: FIXED → ---
Blocks: 125824
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?
*** Bug 133208 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.0.1
changing OS to Mac...
OS: All → Mac System 9.x
Hardware: All → Macintosh
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.
Blocks: 181527
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?
Over to a more real owner....
Assignee: law → blaker
Component: Printing → XP Apps: GUI Features
OS: Mac System 9.x → MacOS X
QA Contact: sujay → paw
This is still an issue for Camino. See Bug 220201.
Could some one take a look at this again?
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.
Assignee: firefox → guifeatures
Product: Core → Mozilla Application Suite
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?)
Blocks: 202014
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).
Closed: 23 years ago19 years ago
Resolution: --- → FIXED
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.