Closed Bug 242134 Opened 20 years ago Closed 19 years ago

print page setup headers and footers are not remembered

Categories

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

Product:
Core
Component:
Printing: Output
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: Peter6, Assigned: mkaply)

References

Details

Attachments

(3 files)

Remove printer specific prefs for page setup
1.42 KB, patch
Details | Diff | Splinter Review
print.printer screenshot
7.42 KB, image/png
Details
testcase
5.40 KB, text/html
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040423 Firefox/0.8.0+ (JTw)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040423 Firefox/0.8.0+ (JTw)

print page setup headers and footers are not remembered.
prefs.js setting:
user_pref("print.printer_Brother_HL-1430_series.print_footercenter", "");
user_pref("print.printer_Brother_HL-1430_series.print_footerleft", "");
user_pref("print.printer_Brother_HL-1430_series.print_footerright", "");
user_pref("print.printer_Brother_HL-1430_series.print_headercenter", "");
user_pref("print.printer_Brother_HL-1430_series.print_headerleft", "");
user_pref("print.printer_Brother_HL-1430_series.print_headerright", "");
user_pref("print.printer_Brother_HL-1430_series.print_in_color", true);
user_pref("print.printer_Brother_HL-1430_series.print_margin_bottom", "0");
user_pref("print.printer_Brother_HL-1430_series.print_margin_left", "0");
user_pref("print.printer_Brother_HL-1430_series.print_margin_right", "0");
user_pref("print.printer_Brother_HL-1430_series.print_margin_top", "0");

All these values show coorectly in File->Page setup.
But every time the browser is first opened every day I have to go to
File->Page setup->Margins&Header/Footer and press OK to make sure that the
settings are used when I print a page.
If I don't do this some vague marginvalue is used and both header and footer are
printed.

Reproducible: Always
Steps to Reproduce:



Expected Results:  
Printing should be in accordance with the settings in prefs.js
OOps, made an error by V-ing security, which is nonsense offcourse.
Group: security
*** Bug 227349 has been marked as a duplicate of this bug. ***
Flags: blocking1.0?
WFM.  If I restart Firefox and print preview, or if I restart Firefox and print,
my header/footer settings (page number only) are applied correctly.  Mozilla/5.0
(Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040426 Firefox/0.8.0+

Do you see this bug with print preview or just with printing?
Just with Printing Jesse, I never look at the preview.
And only after first start or reboot
Maybe this is fixed in Moz1.8a , if so I'd like to see it fixed in 1.0.
> And only after first start or reboot

Is restarting Firefox sufficient to trigger this bug, or do you have to restart
Windows?
I just tested all options, 
It does allways occur unless "File->Page setup->Margins&Header/Footer and press OK"
If I close FF and reopen again I will have to "File->Page
setup->Margins&Header/Footer and press OK"

Ergo, it only remembers the prefs.js setting during the current session and only
after one "File->Page setup->Margins&Header/Footer and press OK".

Exactly the same as that it refuses to remember to use A4 i/o Letter format
(other bug)
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a) Gecko/20040502
Firefox/0.8.0+
I can confirm this is Fixed in the trunk builds, but not in the branch builds
(last one tested 2004-04-23)
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040524 
Firefox/0.8.0+ 

changed to WFM
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040524 
Firefox/0.8.0+ 

changed to WFM

It's what they call a nightmare, in some builds it works and in some it doesn't
(by far most of the time).
REOPENING because it still isn't right.
adding the printersettings also to user.js made no difference, the first time I
open FF after the computer is turned on I must OK the Page Setup or I get the
default header/footer setting. Just pressing OK is enough to set it.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Just and update that this bug is still present in the new .9 release candidate.
 To me this is a pretty big bug.  I have a web app that uses printouts from FB
for customer correspondence.

Again, the headers and footers show up on the first page regardless of the
settings.  This is eminently reproducible.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040609
Firefox/0.8.0+
I confirm the bug is still there using a cleanly installed FF0.9RC
Please tell me if an example is required ?
I use an iframe to print my forms from. using frames[0].print(); to print the
iframecontent.
We use a lot of forms at the office and aren't happy to use IE, just because FF
refuses to set the proper settings at startup.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hi! I have the same problem. I think it is a really simple bug to fix.

Somehow Firefox doesn't load the print settings from the configfile at startup
and you have to go to the 'Page Setup' menu and click OK, and then it set the
settings correctly.

A way to trigger this bug is to go to Page Setup and set margins to 0 and set
headers+footers to blank and then click OK. Then exit Firefox, maybe restart
windows and then open firefox.
Don't go to Page Setup, but just go to a random page and print it, and you will
see the headers are still there.
Then go to Page Setup, don't change anything, just hit OK and then print the
page again, and now the headers is removed correctly.

Please fix this bug soon! :]
I tried exactly the scenario in the last comment and did not see the problem.

Just to clarify, these settings are printer specific, so you need to print with
the same printer they were set with...

Maybe that is the problem here.
This patch makes it so that page setup affects all printers.

This is very logical, since there is no way to know which printer page setup is
affecting.
Assignee: firefox → mkaply
Status: NEW → ASSIGNED
Attachment #150952 - Flags: review?(bugs)
Comment on attachment 150952 [details] [diff] [review]
Remove printer specific prefs for page setup

Tim, can you please give your opinion on this change.
Attachment #150952 - Flags: review?(bugs) → review?(tor)
mkaply:
IMHO it would be better to kill the XUL "Page setup" dialog completely and move
that functionality into the XUL "print job options" dialog. IMHO many users
would be much more happier with that.
(In reply to comment #17)
> IMHO it would be better to kill the XUL "Page setup" dialog completely and move
> that functionality into the XUL "print job options" dialog. IMHO many users
> would be much more happier with that.
Firefox does not have the "print job options" dialog.
Or is this planned for 1.0beta or 1.0 ?


Peter van der Woude wrote:
> (In reply to comment #17)
> > IMHO it would be better to kill the XUL "Page setup" dialog completely and 
> > move
> > that functionality into the XUL "print job options" dialog. IMHO many users
> > would be much more happier with that.
> 
> Firefox does not have the "print job options" dialog.
> Or is this planned for 1.0beta or 1.0 ?

On Unix/Linux open the print dialog, click on "Properties..." and the print job
options dialog should appear. That's the beast I am talking about...
(In reply to comment #15)
Michael Kaply (IBM) wrote:
> Created an attachment (id=150952)
> Remove printer specific prefs for page setup
> 
> This patch makes it so that page setup affects all printers.
> 
> This is very logical, since there is no way to know which printer page setup is
> affecting.

Michael, this is NOT about multiple printers, it's just one.
Somehow the settings that are shown in page setup and are defined in user.js are
not implemented.
Only pressing the OK button (in page setup) makes sure the settings will be used
by FF.
Every time I startup the computer and want to print the form I first have to
open page setup, press ok, and the settings from user.js will be implemented.


You can't put settings for this in user.js - you wouldn't know what format to
put it in since it is unique to the name of printer.
Oops, I typed w/o checking, prefs.js I meant.
Flags: blocking1.0? → blocking1.0+
Priority: -- → P3
Flags: blocking-aviary1.0RC1+
Flags: blocking-aviary1.0RC1+ → blocking-aviary1.0RC1-
This is listed as a Windows bug, but I also have this problem on a Mac. Firefox
0.9.1, Mac OS 10.3.4. The "choose page setup and click OK" work-around mentioned
does not work for me on the Mac. I can't get rid of the headers and footers at all.
OS->All
OS: Windows 2000 → All
Is there anything I can do to escalate this bug?  I am using .9.3 and this
problem is still alive and well.

To restate the bug: the header/footer preferences are not implemented when you
print a page.  You must go to the Page Setup and click on OK for the preferences
to work.

If nothing else, to fix this, would it be possible to refresh the settings
automatically from the user preferences (or re-initialize) every time the print
print dialog is opened?
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040901
Firefox/1.0 PR (NOT FINAL)

Still a problem
in about:config  I found the prev 
 print.use_global_printsettings=true (maybe this should be false ?)

I also found 
 print.print_extra_margin = 0 (I changed it)
 print.print_footerleft =  ( I changed this one to empty )
 print.print_footerright =  ( I changed this one to empty )
 print.print_headerleft =  ( I changed this one to empty )
 print.print_headerright =  ( I changed this one to empty )
this made no difference.





Bug #249432 same problem.
Bug #255007 same problem.
Bug #255960 same problem.
Bug #238916 same problem.

Seems to be related to source bug, a Locale-error?
Some function doesn't seem to receive in correct form the Windows locale info,
and  Initialization code falls back to default... This is all I have found from
this printing preferences error..
I think the problem you are seeing, although it is very non obvious, is that
page setup options are associated with a particular printer (either the default
printer if you just started firefox or the last printer you printed with).

Take this is example.

Given printer 1, printer 2, printer 3, where printer 1 is the default printer.

Start Firefox.
Set Page setup and change margins to 3 inches.
Print to printer 1.
Margins are 3 inches.
Now print to printer 2.
Margins are NOT 3 inches.
Now if you go to page setup, you will see margins are back to default and you
have to change them to 3 inches and they will be set that way for printer 2.

Is this what people are seeing?


(In reply to comment #29)
> I think the problem you are seeing, although it is very non obvious, is that
> page setup options are associated with a particular printer (either the default
> printer if you just started firefox or the last printer you printed with).
> 
> Take this is example.
> 
> Given printer 1, printer 2, printer 3, where printer 1 is the default printer.
> 
> Start Firefox.
> Set Page setup and change margins to 3 inches.
> Print to printer 1.
> Margins are 3 inches.
> Now print to printer 2.
> Margins are NOT 3 inches.
> Now if you go to page setup, you will see margins are back to default and you
> have to change them to 3 inches and they will be set that way for printer 2.
> 
> Is this what people are seeing?
> 
> 

Not me ,
I use a single printer (set windows default).
All settings were set in a previous session (previous day)
All settings are correct in prevs.js
All settings show up correctly when you look in Page setup.
-If you print without touching "page setup" it will use Firefox default
-If you print confirming page setup (open and press ok) it will use the custom
settings

This is only a matter of when Firefox is first opened the custom settings will
be set in the page setup dialogue, but they are NOT implemented.



You're going to make me delete all my printers, aren't you :)
(In reply to comment #31)
> You're going to make me delete all my printers, aren't you :)
Nope, just set 1 printer + custom settings as default, print a page (as check).
Close Firefox
Reboot
Open Firefox
Open a page
Press print.

One would expect the proper printer, including custom settings to be used, they
are not.



Here are the steps I took. I still can't recreate the problem. Please tell me if
I missed something.

I did reduce my printers down to one to eliminate confusion.

I printed a page and it printed normally.
I went to page setup and set margins to 3 inches on all sides.
Printed a page, it printed with margins of 3 inches.
Closed Firefox.
Restarted firefox.
Printed a page, it printed with margins of 3 inches.
Closed firefox
rebooted
Printed a page, it printed with margins of 3 inches.
What is the name of your printer?

Can you go to about:config and type print.printer and post a screenshot of the
preferences?

Thanks
see screenshot
I'm at a loss. I simply can't recreate the problem.  I set my printer
preferences to be exactly the same as yours. When I start firefox for the first
time, it uses the preferences of the default printer in the operating system.
What do you have set as your default printer in Windows?
Michael, gimme 30 minutes to create an attachement (html) as testcase.
Attached file testcase — 
repro:
1) assuming you still have my setting (essential)
2) after reboot start Firefox
3) open testcase , bill.html
4) go to the right of the word "naam:" and select a person from the selectbox
5) go down and press on the button "print Bill"
6) this will create the bill layout in the iframe and brings up the native
(win) print dialogue
7) Press [OK] in the print dialogue to print the bill
 result, despite all efforts to remove filename date time etc from the
headers/Footers, it prints them anyway.

8) go to Menu File->Page Setup->Margins/header&Footer and press [OK] (don't
tough anything else)
9) now press [Print Bill] again.

Result, Bill printed as it should

From now on all printersetting will be obeyed ... untill the next time you
start up the computer
not going to block the release for this but we'd consider a patch for approval
if it wasn't scary.
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
*** Bug 264287 has been marked as a duplicate of this bug. ***
*** Bug 264419 has been marked as a duplicate of this bug. ***
*** Bug 265801 has been marked as a duplicate of this bug. ***
*** Bug 216688 has been marked as a duplicate of this bug. ***
*** Bug 205325 has been marked as a duplicate of this bug. ***
Basically, its not only the headers and footers that are forgotten. None of the
changes you do in the Print Preview are remembered for the next session.
Michael:

With all of the duplicates of this bug, it is clear that a bug exists.   If you
can't reproduce it, please consider reassigning the bug or finding a developer
that can reproduce it.  This has been a bug for over 6 months.
We don't have developers that can reproduce it. That's kind of the problem.
Michael:

Alright.  We need to get a developer to find the behaviour.  Here is what I do
to reproduce the bug:
#1) go to page setup...for margin and footers I have .5 inch margins, and blank
headers and footers
#2) close all and reboot
#3) start up FF
#4) File->Print->OK
#5) page with headers and footers prints!
#6) go to page setup, look at margins/headers/footers tab, click ok
#7) File->Print->OK
#8) page without headers and footers prints!

I usually install the FF updates over the old FF editions.  Maybe I have
something in my user profile, or some old file that is causing this?

I will do my best to help track down this issue.  Just let me know what
information I can provide.

Troy

Had you printed to the same printer in both these cases?

How many printers do you have?
(In reply to comment #47)
> I usually install the FF updates over the old FF editions.  Maybe I have
> something in my user profile, or some old file that is causing this?
> 
> I will do my best to help track down this issue.  Just let me know what
> information I can provide.
> 
> Troy

You can do that since 1.0PR.
I can duplicate your case 100% of the time with a new profile/install.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0


5....here's a screenshot: http://www.geocities.com/djlurch01/ff_bug.gif
5....here's a screenshot: http://www.geocities.com/djlurch01/ff_bug.gif

The OKI is the one I use to print and reproduce the errors.
Is the OKI your default printer? in Windows.

The thing that people might not understand here is that page setup is tied to a
particular printer. So if you customize it, you are not necessarily customizing
it for the OKI and there is no way to know.

The interface is VERY bad.
Michael:

The OKI is my default printer.  Maybe Peter has an OKI too?  Then we could
narrow it down to a manufacturer issue.

>The interface is VERY bad.

What do you mean when you say this?  Which interface?

>The thing that people might not understand here is that page setup is tied to a
particular printer. So if you customize it, you are not necessarily customizing
it for the OKI and there is no way to know.

But the headers/footers don't bug out using IE or Opera...so it's not solely the
fault of the printer settings.  FF is involved on some level (IMHO).


(In reply to comment #53)
> Michael:
> 
> The OKI is my default printer.  Maybe Peter has an OKI too?  Then we could
> narrow it down to a manufacturer issue.

Even though I originally reported this bug for Mozilla (bug 216688), it seems
likely that we're looking at the same issue. And I haven't used an Oki since the
80's, so it's not a manufacturer-specific problem.

When I get some time I'll try to reproduce the problem as I first encountered
it. I'll report back ASAP.
(In reply to comment #54)
> When I get some time I'll try to reproduce the problem as I first encountered
> it. I'll report back ASAP.

Okay, I checked. I reported it over a year ago in Mozilla (where the bug remains
in UNCONFIRMED status), and it still persists today in Firefox. Same symptoms,
same steps to reproduce. 

I'm using a completely different system than I was a year ago (I'm now at a
different company), so it's obviously not a system-dependant issue. I'm
currently printing to a big Toshiba copier/printer. Last year it was to an HP
LaserJet 4. Networked in both cases -- I don't know that has anything to do with it.

BTW, I didn't think the "Page Setup" dialog off of the "File" menu was printer
specific. It's the exact same dialog regardless of printer being used (and
regardless of what individual settings are made in the printer settings dialogs).
Duplicated with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5)
Gecko/20041018 Firefox/0.9.1+.

This bug is driving me crazy as I am doing a lot of specific header printing.

I don't even have the consistency that other posters describe.  I can't find any
unifying principle as to when header changes are remembered and when they are
forgotten.  It does seem like they are forgotten when I change printers, but not
always.  Also, sometimes the "page setup" settings are updated to the forgotten
settings so I can at least know I've lost my custom settings, but sometimes they
are not.

Please help!
To reproduce, try this process that I originally reported for bug 216688:

If Page Setup is used to change settings from "Shrink to fit" to a scale value 
(like 85%, for instance), the change will be in force for all mail printed 
during that session. However, if Mozilla is exited and restarted, "Shrink to 
fit" is once again the default.

Reproducible: Always

Steps to Reproduce:
1. Select a web page to print.
2. Choose File|Page Setup from the menu.
3. Choose the Format& Options tab.
4. Uncheck "Shrink to Fit" and place a value in the scale field.
5. Print the page.
6. Visit and print other web pages -- the same scale is used, settings are still
in place.
7. Exit Firefox.
8. Restart Firefox, go to a page, select File|Page Setup from the menu 
and examine the settings.

Actual Results:  
The settings had reverted to "Shrink to Fit"

Expected Results:  
If the settings persisted during the session, they should simply persist all 
the time, or at the very least the user should be given the option to save the 
settings as default.
I believe the shrink to fit problem is different.

When I say page setup is printer specific, this is what I mean.

Print to printer 1.

Now go modify headers in page setup. You are modifying them for printer 1.

No print on printer 2

Go back to page setup. Note your settings are gone, because the page setup
dialog is displaying the header setting for printer 2.

This can easily be seen by going to about:config and typing 

print.printer

into the entryfield.

You will see that although in the UI Mozilla it appears you are setting global
margins and header info, you are not - they are stored printer specific.

So I believe the problem here is that when Firefox/Mozilla goes to read the
settings, it is reading the ones for the wrong printer.
(In reply to comment #58)
> So I believe the problem here is that when Firefox/Mozilla goes to read the
> settings, it is reading the ones for the wrong printer.
half the story Michael.
It reads the wrong values to execute the print.
It sets the right values in the Page Setup dialog but does nothing with them
untill you [OK] them


Okay. I tried the header and footer thing. My settings persisted between
sessions (all I did was swap around the locations of things like URL, Date&Time,
etc).

So I can't reproduce that problem -- though I didn't try the multiple printer
thing, nor did I mess with the margins.

My other problem (which was marked as a duplicate of this bug for a short while)
is completely reproducable each time, however...
Question -- should I re-submit bug 216688 as a Firefox bug since I originally
reported it in Mozilla? I'm guessing it also appears in Thunderbird as it was in
the mail section of Moz where I first noticed it.
I would like to add this - 

Printer properties set to Duplex printing / booklet which is printer specific.  

I am printer continuously through different web pages.

I would like Firefox to remember this setting atleast for this session [until I
quit FFx]

Currently this doesn't happen, and I have to do the settings again and again [bad]

Can't this be set right?
I would like to add this - 

Printer properties set to Duplex printing / booklet which is printer specific.  

I am printing continuously through different web pages.

I would like Firefox to remember this setting atleast for this session [until I
quit FFx]

Currently this doesn't happen, and I have to do the settings again and again [bad]

Can't this be set right?
Here's my version of this problem. 
First it only began to occur after I used the custom setting on a footer. After
I print using the custom footer, I always reset the footers and headers (all 6
fields are different) to my general preferences and often print something before
closing FF. 
The next time I print from FF, it will print using the previously changed custom
hrs/ftrs.  This happens both with the first time I print from FF after starting
up for the day, and if FF printing has been idle for quite some time (> 3
hours,or so) and I print again. When I go into the page setup hdrs/ftrs, they
are what they should be (i.e., the way I last set them, not the custom ones). 
The interesting part: 
I print a lot from the Web, and one time I forgot to go back to the page setup
after the printing with wrong hdr/ftr to "reset" and the next print output was
correct.  Basically, the first print job is wrong (has the previous custom
setup), then the ones after that are fine with the correct hdrs/ftrs. (Unless,
as I said earlier, there's a huge gap in time between.) This happens all the
time (no exceptions) - day after day.  

Was using FF .8 and now preview 1.0. Using Windows XP home with two printers:
Lexmark and Adobe Acrobat Distiller. 
We do have the same problem with FF 1.0 with fresh install of FF and Win98.

We have NETWORK printer, may be this is a point?

Or may be "default printer" and "particular printer" (which is used to print and
is single and default printer in system) - are different printers from FF's
point of view?
Flags: blocking-aviary1.1?
I have pretty mmuch the same behaviour as every one else. In bried: Firefox
doesn't apply Page Setup until you open the Page Setup dialog after a Firefox
launch.
Feature enhancment request
A great feature around this bug would be a check box on the print dialogue that 
allows a user to ask firefox to remember the Printer settings (duplex, colour, 
staple etc.) and the page setup for a specific URL.
One page I use regularly requires landscape printing for best effect and 
another requires portrait and colour. constantly changing these settings is a 
pain.

In Mozilla/5.0 (Windows; U; Windows NT 5.1; nl-NL; rv:1.7.6) Gecko/20050318
Firefox/1.0.2, the problem still exists.
I write this bug report to confirm that the bug "print page setup headers and
footers are not remembered" is still present with version 1.0.3 of Firefox, I'm
using the Italian version.

This is very annoying because I am using Firefox as a client for an intranet
application for writing medical reports, and the title and url often show up in
the reports. That messes up all my formatting and allignment efforts.

The problem,not consistently, disappears when I once use "print preview" before
e printing session, but sometimes it reappears unexpectedly (I apologize for
spelling errors).

My system is an intranet with a HP1000 laser printer on a Windows XP PC, but the
PHP application is on GNU/Linux Fedora Core 2 running apache, but that should
not make any difference.

If someone has a clue or a suggestion on how to fix this please send me a email
at danyliscia@libero.it

Best regards

Daniel Liscia
on IRC from Tor, patch is no-good
Developers:  How about you stop ignoring this bug!  This has gone on long
enough.  Let's get some action on this.  For those of us in the document
printing field this is a major error.  

This bug has been present for OVER 2.5 YEARS.  This thread is only one of the
recent discussion.  Check the marked duplicate/closed bugs and you will find it
goes back to 2003.

At this point I no longer care if I make some waves here at Bugzilla.  This
thing has been ignored way too long...and it is clearly a widespread issue.

I have version 1.0.4 installed and it is still occurring.  It occurs on all 3
PCs on my network and has occurred on 2 separate printers.  I have offered to
provide additional information several times.

Bugwatchers/Reporters: this is a confirmed bug that these folks don't seem to
care about.  Get creative and push this thing towards resolution.
troy: so fix it yourself. this bug is in terrible shape. I'm a developer and i
can't figure out what's going on, I'd also never have found this bug if i was a
normal developer.

some comments talk about print preview, some don't, this is confusing me.

anyone else who comments in this bug about having problems should provide at least:
* print name, vendor, model number
* printer driver versions
* their OS version (major, minor, service pack)

= the next few people who provide steps should painfully indicate precisely
whether they're using a keystroke, menu or button (and which) for each and every
step. [this applies to both of the following bullets, a monkey that can follow
oral instructions should be able to follow your steps - the monkey will not be
given pictures, so don't post any]
* precise steps demonstrating the problem in Mozilla or Firefox (specify and
specify version + any extensions you've installed [hint: the fewer you have
installed, the fewer you need to specify] and URL you used to retrieve this animal)
* equivalent behavior description for notepad (if they're experiencing the
problem on a platform other than windows, they should specify the notepad
equivalent and the equivalent behavior).

beyond that, if people experiencing this problem are willing to build their own
versions of Mozilla, that'd be a good start, since this seems like a series of
initialization / serialization issues, which hopefully some printfs or
breakpoints narrow down.

if you aren't willing to do that, perhaps we could arrange for NSPR logging
which did it.

I have no clue why this bug was filed under Firefox/Menus, but i can assure you
that most developers would never look for this bug there.
Assignee: mozilla → djlurch01
Status: ASSIGNED → NEW
Component: Menus → Printing
Flags: review?(tor)
Product: Firefox → Core
Version: unspecified → Trunk
oh, and everyone should indicate the value they have for
print.use_global_printsettings

i don't understand the code at this hour (it's past midnight), but the code is
very frightening.
QA Contact: bugzilla → printing
the original bug i filed:

despite the following settings:

|  use_global_printsettings true
|  user_pref("print.printer_Brother_HL-1430_series.print_footercenter", "");
|  user_pref("print.printer_Brother_HL-1430_series.print_footerleft", "");
|  user_pref("print.printer_Brother_HL-1430_series.print_footerright", "");
|  user_pref("print.printer_Brother_HL-1430_series.print_headercenter", "");
|  user_pref("print.printer_Brother_HL-1430_series.print_headerleft", "");
|  user_pref("print.printer_Brother_HL-1430_series.print_headerright", "");
|  user_pref("print.printer_Brother_HL-1430_series.print_in_color", true);
|  user_pref("print.printer_Brother_HL-1430_series.print_margin_bottom", "0");
|  user_pref("print.printer_Brother_HL-1430_series.print_margin_left", "0");
|  user_pref("print.printer_Brother_HL-1430_series.print_margin_right", "0");
|  user_pref("print.printer_Brother_HL-1430_series.print_margin_top", "0");

and the fact that these prefs show up in File->Page Setup ->Margins&Header/Footer

Firefox will use the default values (embedded in the app.) unless the user goes
to File-> Page Setup-> Margins&Header/Footer and presses [OK].

this has to be done once per windows session, after that these prefs will be used.

after a reboot/restart the user must go to File-> Page Setup->
Margins&Header/Footer and press [OK] again to implement them again.

so this may aswell belong to Firefox:Preferences ?
> File-> Page Setup-> Margins&Header/Footer

Instead of going there and pressing Ok, 
does opening up 'about:config' (type it in the url bar) work?



(In reply to comment #75)
> > File-> Page Setup-> Margins&Header/Footer
> 
> Instead of going there and pressing Ok, 
> does opening up 'about:config' (type it in the url bar) work?
> 
Yes, all the above mentioned values show up in about:config


(In reply to comment #76)

> Yes, all the above mentioned values show up in about:config

My question was whether opening 'about:config' gets those options effective
(instead of default values) when you print. 



this is stupid. firefox doesn't honor use_global_printsettings. fwiw i get mail
for just about every bug in existence, don't bother cc'ing me.
(In reply to comment #77)
> (In reply to comment #76)
> 
> My question was whether opening 'about:config' gets those options effective
> (instead of default values) when you print. 

I booted the computer
1. Open Firefox
2. open about:config (not changing anything)
3. open the page i want to print
4. print the page (without touching page setup)
5. headers/footers are printed :-(
Assignee: djlurch01 → mozilla
timeless@bemail.org changed this bug and assigned it to me.  I am not a FF
developer.
Flags: blocking-aviary1.1? → blocking-aviary1.1-
I've installed firefox 1.0.4 on a lot of computers in an hospital (25 Windows XP
PCs and 8 Mac OS X). They all have differents printers and use firefox to
consult an intranet application.
The PCs don't remember the headers and footers settings until the File->Page
Setup->Margins/header&Footer [OK] button is pressed and for the Macs, you don't
even have a Margins/header&Footer menu.
As intranet web applications are getting more and more used, firefox has to
become printer friendly. This bug has to be set to a higher priority. Can any FF
developper fix this bug once for all ?
Does anyone have a work around for this yet?

I have two printers on my machine.  Both printers are set to "blank" header and
footers in the "about:config".  Also, the default print.header/footer values are
also set to blank.  Same with the user preference file.  However, FireFox
forgets this because every time I restart FireFox it reverts back to printing
the header and footers.  Is this hardcoded into the application itself?  Or, are
there other configuration settings that I'm missing here?

When I go into page setup to check they still come up as "blank".  I have to
click  OK to get the headers and footers to go away again.  The whole problem
comes back if I restart FireFox.

It appears this issue has been reported for over 1 year.  It's quite disturbing
that a problem which seems so minor has gone unresolved for so long.
*** Bug 303204 has been marked as a duplicate of this bug. ***
*** Bug 279784 has been marked as a duplicate of this bug. ***
Please note that I recently reformatted and installed XP fresh with a copy of FF
1.0.7 and the problem STILL exists. FF developers are ignoring this problem.
Once again I would like to plead with those that are in the loop to push this
problem to the top of the list any way they can.

I have had this problem on about 20 fresh installs of XP.

I have a networkprinter. Could that be the problem? Is the problem only
acquiring on FF installs with a network printer? Can anybody confirm this?
(In reply to comment #86)
> I have had this problem on about 20 fresh installs of XP.
> 
> I have a networkprinter. Could that be the problem? Is the problem only
> acquiring on FF installs with a network printer? Can anybody confirm this?
makes no difference


I also am getting a little irritated with this one.  I print from Firefox 
DAILY, and always have to go into the Page Setup dialog to get the headers and 
footers off.  Really guys, how hard can this bug be?  It seems obvious that FF 
just isn't loading the settings when the browser initiates.  Go into the 
initialization function or constructor or whatever it is, and make it load the 
headers from wherever the data is stored.  I'm talking this is like a 10 
minute fix, MAX.  Please for the love of all the people who died this year, 
FIX THIS BUG!

David
Although I am unsure as to the full status of this bug currently, I'd just like
to let you guys know a couple things:
1) When this gets fixed, it will first appear on the Trunk builds.  Later on,
after testing and whatnot, it will be added to the Branch builds which
eventually become official releases (e.g. 1.0.7, 1.5.0).
2) Complaining about bugs on Bugzilla isn't helpful; if you want to do it at
all, do it on mozillazine.org's forums or even irc.mozilla.org provided you are
nice about it.
3) If the bug applies to you, add your vote to it and move on.  You'll be
emailed when the bug gets fixed and whatnot.
Ok Matt, what can I do to help?  I have no knowledge of the firefox source
files.  I went to look at them, and I don't think I can even unpack them without
putting at least a half hour into figuring out how to do that.  Much less do I
have any Unix, make, or autoconf tools experience that the build page says is
necessary (http://developer.mozilla.org/en/docs/Build_Documentation).

But I'm a proficient C++ developer, and anxious to get this thing solved.  What
kinds of testing or diagnostics can I do to help things along for the guys who
know the code?
Blocks: 125824
*** Bug 279028 has been marked as a duplicate of this bug. ***
*** Bug 284534 has been marked as a duplicate of this bug. ***
*** Bug 254452 has been marked as a duplicate of this bug. ***
*** Bug 312384 has been marked as a duplicate of this bug. ***
BTW, I don't know if it matters, but the same behavior exists in Thunderbird, as
well. However, the bug reported there was closed -- "EXPIRED" due to inactivity.
I am not a developer, I can only report the problems I find, so I don't know if
fixing this bug will also fix the Thunderbird bug. 
(In reply to comment #96)
> BTW, I don't know if it matters, but the same behavior exists in Thunderbird, as
> well. However, the bug reported there was closed -- "EXPIRED" due to inactivity.
> I am not a developer, I can only report the problems I find, so I don't know if
> fixing this bug will also fix the Thunderbird bug. 
That bug probably should have been duped to this one


I can confirm this is still present. I've had this from FF 1.0 all the way to what I use now, 1.07. It happens on 7 machines here in the office, all on the same version. All on Windows XP Pro SP2. It is to both networked printers as well as local printers. 

I get exactly what Peter reported. Page Setup preferences are not 'remembered' and only kick in once you actually go in and confirm the settings. 

Say I boot a machine now and open FF as is. 

I go with the mouse File -> Page Setup... and see that the two tabs have all the right settings (all headers & footers blank). But if I print now it will add headers and footers. However, if I 'confirm' those settings by clicking OK under these two tabs, it will use those settings (no headers or footers). It keeps 'remembering' until FF is closed.

This happens on all printers. Brother QL 550, Brother HL 5140, Brother HL 5040. Drivers are mostly the latest ones as per the manufacturer's websites. The 5140 is local to me but network users get the same. It's on LPT1. The 550 is on USB and so is the 5040. 

We print around 50 individual web pages daily from FF so you can imagine the hassle of having to confirm the already entered preferences again and again.

Here are my about:config entries which seem related:
print.save_print_settings | default | boolean | true
print.use_global_printsettings | default | boolean | true
print.use_native_print_dialog | default | boolean | true
print.always_cache_old_pres  | default | boolean | false

Extentions I use include Webdeveloper Toolbar 0.9.4, Tab Browser Preferences 1.2.8.7, googlebar 0.9.5.06, Wayback 0.2, Bookmark Backup 0.3.3 though I had less on previous FF versions and remember this issue always being present.

I think it was Mike who mentioned here these settings are printer specific (I see one printer in about:config though there are more in the print dialog) though how would be loop through all printers and set them individually?
In (my) Firefox 1.5 runnning on XP SP2 the bug has been fixed! Thanks!
I confirm that on my machine, this bug was fixed in 1.5.  (Windows XP Home SP2)

Thanks a million guys!  I owe the person who fixed this a beer next time I see him/her.

Kind regards,
David --  dbergan,gmail

PS Of course, now I'm completely in the habit of doing the page setup routine...
Yep, this looks like having been fixed.
Resolving WFM (I guess no one know which bug fixed this)
Status: NEW → RESOLVED
Closed: 20 years ago → 19 years ago
Resolution: --- → WORKSFORME
*** Bug 318362 has been marked as a duplicate of this bug. ***
Problem still exists for me with Firefox 1.5.0.4 on Windows XP Home. Although my
print default settings are visible in the dialog box, they are not applied after
start up unless I open the Page Setup... dialog and click OK.
(In reply to comment #103)
> Problem still exists for me with Firefox 1.5.0.4 on Windows XP Home. Although
> my
> print default settings are visible in the dialog box, they are not applied
> after
> start up unless I open the Page Setup... dialog and click OK.

Gave up on Firefox after this and another similar problem weren't resolved and there was no likelihood of a resolution.

I consider that is a fundamental flaw and when I saw how long it was since it was first reported, my confidence in Firefox went right down.  

All of a sudden, IE6 wasn't so bad after all!

(In reply to comment #104)
> (In reply to comment #103)
> > Problem still exists for me with Firefox 1.5.0.4 on Windows XP Home. Although
> > my
> > print default settings are visible in the dialog box, they are not applied
> > after
> > start up unless I open the Page Setup... dialog and click OK.
> 
> Gave up on Firefox after this and another similar problem weren't resolved and
> there was no likelihood of a resolution.
> 
> I consider that is a fundamental flaw and when I saw how long it was since it
> was first reported, my confidence in Firefox went right down.  
> 
> All of a sudden, IE6 wasn't so bad after all!
> 

I am also thinking printing will be the demise. So many little things get attention, but printing goes nowhere.

The bug persists on Firefox 3.0.5, Windows and Linux. And worse, the printer config looks completly broken (errors on tabs drawing, reffuse to accept zoom option, ignores orientation and scaling, and much more errors on dialog and print preview).
(In reply to comment #106)
> The bug persists on Firefox 3.0.5, Windows and Linux.

Hmm -- can you file a new bug for this in Firefox 3 (with steps to reproduce)?  It's pretty likely to stem from a different root cause from whatever caused this original bug, because this bug apparently became WFM for many people at some point, and also because the layout & printing code engine have had significant rework since the timeframe when this bug was originally filed. (Also, this bug page is massive, and reopening it to restart the discussion would be quite messy.)

> And worse, the printer
> config looks completly broken (errors on tabs drawing, reffuse to accept zoom
> option, ignores orientation and scaling, and much more errors on dialog and
> print preview).

That sounds like a different issue.  Could you file a different bug on that, with steps to reproduce and ideally with screenshots of the broken-ness?  

CC me on both bugs, please -- thanks for reporting these problems!
Hum... More news: The print dialog do not have the same problems on XP and Linux anymore (my XP machine is at home and Linux machine is at work). But I recently reformatted the XP machine and seens to work now. Maybe a problem with old config files? Is the same firefox 3.0.5 on Linux and XP.

But on Linux is a mess. The dialog is not rendered correctly, the text looks wrong and is difficult to force then to remember the config. I will make a screenshot to you tomorrow from Linux machine, will be more easy to show the problems
(In reply to comment #108)
> Hum... More news: The print dialog do not have the same problems on XP and
> Linux anymore

That's good to hear.

> But on Linux is a mess. The dialog is not rendered correctly...

Strange -- I use Linux, and I haven't seen that problem.

Again, though -- please file a new bug, rather than posting about it here. Commenting here just makes this already-too-long bug-page harder to read, with comments unrelated to the original problem. It makes it harder to track both this bug's original issue and the issue that you're bringing up now.

File bug here: https://bugzilla.mozilla.org/enter_bug.cgi?product=Core
Please choose component "Printing: Setup" for the dialog issue.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: