279784 - setting header/footer all blank save, but on new brower launch, still print

Status: RESOLVED DUPLICATE of bug 242134

(Firefox :: General, defect)

Description

[Bane Lob]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Having to go into the file/page setup/ margins & header/footer and click OK each
time I open a fresh browser environment is getting tiresome.

The settings in the Margins & header/footer are all saved from session to
session, ie. all fields are set to --blank-- when I open up a browser for the
first time, but the default settings for those fields, ie. print the date, url,
and page number of total [ page 1 of 1] appear on the printout.



Reproducible: Always

Steps to Reproduce:
1.in page setup, set all 6 header/footer pulldowns to --blank--, click OK
2.close all browser windows, and open up a new firefox or mozilla, go to any
webpage, and print it, finding the default header footer and page number printed
on the page
3. go into page setup, note that all 6 fields are still --blank--, click OK, go
to any webpage and print, finding no header or footer printed on page

Actual Results:  
on initial browser open, header/footer information is printed even though
settings are all --blank--, UNTIL the OK is clicked.

Expected Results:  
on initial browser open and print any page, the header/footer should follow the
settings placed by user, not default settings.

This is a problem of security, as there are times where printing the URL could
lead to attempts to access server pages that should not be known outside office
personell.  Some pages are printed for customers, and they should not see URL
information on their copy.

Comment 1

[Seph M. Soliman]

I confirm this bug.

I made a web based administration system for a cleaning company, and recently
added a "print-direct" button on the invoice-page, but with firefox, this
results in headers beging set to default, margin to default so the page is all
screwed up. 

My method of direct-printing is a clickable image that opens a popup that calls
window.print(); and then window.close(); so the window closes when you choose Ok
or Cancel to printing.

Comment 2

[Seph M. Soliman]

I confirm this bug.

I made a web based administration system for a cleaning company, and recently
added a "print-direct" button on the invoice-page, but with firefox, this
results in headers beging set to default, margin to default so the page is all
screwed up. 

My method of direct-printing is a clickable image that opens a popup that calls
window.print(); and then window.close(); so the window closes when you choose Ok
or Cancel to printing.

Comment 3

[Jessica Dressler]

I have the same problem I wrote a quoting program for my company and they are
not liking me for the fact they have to click okay on the headers and footers to
show up blank.  They want it fixed.  

       Jessica

Comment 4

[Adam]

I have also run into this issue, but you don't actually have to click OK in the
"Page Setup" window, all i have done to make the program load my user defined
settings, is open up the "page setup" window, then click close.

It seems that the default settings are loaded on startup of the program, and the
user defined settings are ignored until "Page Setup" is opened, then the user
defined settings are loaded, and everything is happy again.  You don't even have
to click on the "Margins & Headers/Footers" tab, or click ok, just click close
and the user defined settings will be in effect.

Comment 5

[Daniel Olivares]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.10) Gecko/20050716
Firefox/1.0.6

It isn't a specific OS bug, in a mac there are not way to deal with this bug. In
"Page setup" there aren't margin nor header options. I tried changing all to
blank on "about:config" the values of:
print.print_footercenter
print.print_footerleft
print.print_footerright
print.print_headercenter
print.print_headerleft
print.print_headerright
and print.print_extra_margin to 0 (zero)

I tried to print again and still appear the default footer and header and crop
the image 1 inch on four borders. Then I tried to write another string in the
above mentioned values and still the default values was printing. There isn't
reading the user configuration so I tried editing directly this values on
/Applications/firefox.app/Contents/MacOS/greprefs/all.js and save the file.
Still is printing the default header and footer and croping the print on 1 inch
as default margin.

I am writing a web client for a financial application that prints on pre-printed
invoices, so i need to print over the 1 inch margin, where are several fields to
 print, and of course the info of header and footer blank.

I think this is a major bug, since there are many web based applications now and
developers want to run it on gecko based web browsers.

Comment 6

[Adam]

OK, i figured out one more thing, the only way i was able to recreate the
problem, was on a computer that had a previous version of firefox installed that
had the problem with the headers and footers.  I have tried to uninstall
everything including deleting the application data file, then reinstall with a
version i know works on a fresh install of windows, but the problem still
arrises.  it seems like firefox does not reset whatever was wrong in previous
versions in order to allow the header and footer settings to stick.  

But when installing the newest version of firefox on a fresh install or windows,
the header and footer settings work as they should.  it is only an issue when
there was a version of firefox previously installed on the computer (one that
had the header and footer problems).  Just thought i'd add this as well

Comment 7

[Bane Lob]

Suggestions that the bug would go away if a new system -- Say WinXP on fresh
install, and latest Firefox, would resolve the issue.  I can deny that this has
had any effect on teh bug, and it has become a sticking point for the adoption
of the browser company wide here.  We cannot have dosuments printed with the
header of the URL which IS on a HTTPS (secure) server, BUT still a security
concern if the site URL is printed on a customer invoice, or other paperwork.

Comment 8

[todd]

This bug appears to be a duplicate of # 242134  
Can the bug owner confirm and mark as duplicate if they agree?

Comment 9

[Bane Lob]

*** This bug has been marked as a duplicate of 242134 ***