Closed Bug 147384 Opened 22 years ago Closed 21 years ago

"Page Setup..." setup isn't conserved between session

Categories

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

Product:
Core
Component:
Printing: Output
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: lapsap7+mz, Assigned: rods)

References

Details

Attachments

(1 file)

Javascript Console err messages
36.88 KB, image/gif
Details 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3)
Gecko/20020523
BuildID:    20020523

In "Page Setup", tab "Margins & Header/Footer", I prefer another arrangement for
headers and footers.  But after they have been changed, quit and reopen Mozilla,
those headers and footers return to their initial arrangement!  Is this a bug or
a feature?

Reproducible: Always
I confirm this bug. RC3 on W2K. I would also raise severity from 'min'. I do not
like the default setup, and sometimes it is important. This is a real annoyance
if the headers and footers are important to the user and I have to remember to
reset them each time. If I forget to reset them, or do not check each time to
see that they are set correctly, it could be a bigger problem.
Feel free to raise the severity :) I didn't put it too high since it seems like
I'm the only one who needs it.  Maybe next one can even raise it a bit higher :)
However, this bug is still unconfirmed :(
No, I cannot raise the severity.
I tried the first time.
I get a message in large font on red field:

> Only the owner or submitter of the bug,
> or a sufficiently empowered user,
> may make that change to the bug_severity field.
At the moment it is meant to be that way.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P3
Target Milestone: --- → Future
Severity: minor → normal
Priority: P3 → --
Target Milestone: Future → ---
Priority: -- → P3
Target Milestone: --- → Future
My company is currently trying to use the ActiveX-Mozilla-component for
printing documents from an application. Everything works perfectly
except there is no ActiveX-interface to control headers/footers and
to enable printing of background colors. As Mozilla is not used for regular
browsing on the machines this application is run we could set a default
setting and this setting would be used then. Now the whole project seems
to be doomed only because we can't turn off headers/footers and print
background-colors. This little bug makes Mozilla as a printing engine 
completely useless which is a pity because it has the best HTML/XML rendering 
by far. Therefore I hope you can look into this a bit earlier. Thanks.
I too would expect the "Page Setup" settings to be saved, just like other user
preferences are. As it is, I have to specifiy my personal settings (small
margin, scale 120%) every time I start Mozilla.

IMHO, this is one of the top usability problems remaining.
this is very annoying!!!
For Unix/Linux bug 166217 ("Print settings on Linux are saved at shutdown but
not read at start") should fix the issue...
Depends on: 166217
*** Bug 167704 has been marked as a duplicate of this bug. ***
*** Bug 169694 has been marked as a duplicate of this bug. ***
mozilla is saving the preferences, but doesn't load it at startup....

try:
1. load mozilla
2. select file > page setup
3. select all header/footer options to "blank", or something else...
4. click "ok"
5. print the page (allright, header/footer didn't print :)
6. close mozilla
7. load mozilla again
8. print the page
9. see the page, browser header/footer is there ://
10. select file > page setup (see that your selections was saved)
11. click "ok"
12. print the page again
13. right now, your selections take action

must I open a new bug?
As for Mozilla 1.2b, header/footer settings seem to work ok now. 

But "Scale" setting and "Shrink to fit" are still not preserved (see comment #6)
nope, I tried on moz 1.2b (win32 and lnx builds) and header/footer still print
out if I don't open "page setup" dialog... :/

how can I help more?
how can I hack the code? :) I really wanna contribute...
I'm dying to see this one get fixed. I really need backgrounds to be printed 
automatically. Even when this option is flagged after restart we need to unset 
& set it again so that it takes it into account. 

Thanks

I can verify comment #11 on moz 1.2b w98.
I need this fixed soon. My users print out cards (~15x8cm) for a dead-tree
database (from a web-app) and the default footer and header is very disturbing.
*** Bug 182921 has been marked as a duplicate of this bug. ***
For those interested: k-meleon (mozilla rendering engine) does the trick 
seemlessly.

http://kmeleon.sourceforge.net/
I like kmeleon and my customers are using it.

Anyway, kmeleon just runs on windows and I think we need this fixed on all
mozilla plataforms.
This should be fixed in the lastest builds
*** Bug 186303 has been marked as a duplicate of this bug. ***
nowadays, moz 1.3a is forgetting all data again.... reproducible in both lnx and
win builds...
Mozilla 1.3b, on win2000 is also lost its previous settings.  Also, please
verify that the javascript .print() command uses the saved page setup settings.
Blocks: 125824
*** Bug 185220 has been marked as a duplicate of this bug. ***
*** Bug 188018 has been marked as a duplicate of this bug. ***
*** Bug 219441 has been marked as a duplicate of this bug. ***
this bug is still present on 1.5RC2.
is any workaround known? the default scale (and not possible to make another
scale as default) makes Mozilla almost unusable for printing in my company.
from my understanding, the bug owner is gone, and the bug in not worked anymore,
is someone who can take the bug? maybe someone change the status from ASSIGNED
to NEW?
With Release 1.4, this bug seems to be fixed as far as retaining Header and
Footer settings are concerned. This is Mozilla on Win2000Pro.
Bug still there in 1.5 Final (10-15-03)... on Windows2000. No since in upgrading
or converting additional users to Mozilla from Netscape until this "BUG" is
"FIXED"...is anyone out there looking at this one?
> No since in upgrading or converting additional users to Mozilla from
> Netscape until this "BUG" is "FIXED"...is anyone out there looking 
> at this one?

since the bug is assigned to "rods@netscape.com (rods (gone))" and the owner is
not working on Mozilla anymore, i think changing the owner (to "Reassign bug to
owner and QA contact of selected component") by someone with enough rights (the
reporter?) may create a chance to get someone to look at it
Nicu...I agree, this bug needs to be reassigned if it's ever going to be
addressed and acted on. My main issue is the "Scale" setting (comment #6). 

I've emailed the QA Contact on this (sujay@netscape.com-returned mail) &
(asa@mozilla.org-no response). 

There doesn't appear to be any mechanism available to bring attention to a
problem other than to create a new bug report...but it's noted that this wastes
QA Engineers time...if you have one I guess.

A fix is in order for this...how about a "DEFAULT" button which are common in
other programs. Change the settings as desired and press DEFAULT. This problem
still exists up to version 1.6 alpha...obviously nobody is doing anything about
it. whew...done venting...for now:-)
BTW..Mozilla 1.6b no better at saving page setup "scale" setting. Note Comment
#19..."should" be fixed in latest builds...how late? Howabout 1.6 Final!!
these settings are saved in a mozilla session, but not across mozilla sessions.
I can look at the code and see if the settings are saved as prefs.
that looks like what we want. Who should review it? I can sr...
Yeah, once bug 223111 is fixed, this one can be marked fixed too.
Depends on: 223111
I believe everything this bug depended on is now fixed. Marking FIXED.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
FYI...nightly build ID:2003121709 (Windows): Page setup doesn't work at all now.
As in doesn't come up?
Sorry..after install, the page setup settings are "blank". You type in settings
and press OK - nothing happens. Only the Cancel button works.
can you check the javascript console for an error please?
As requested....
Sorry about that. Syntax error in checkin. Fix is in.
FYI..fix not in most recent nightly build.
/me is confused as to how that dumb mistake could've gotten by when checking in...

This does work in my local build, really. I've been testing with SeaMonkey, not
FB. Ed, is the remaining problem you're seeing with Firebird or SeaMonkey?
...and what's the build ID?
I'm sure it's SeaMonkey...see comment #37
Ed, the build ID referenced in comment #37 was before mkaply's fix for the
syntax error goofup, did you try a newer build than that (i.e. one from the
18th) and still saw this problem?
Yes...the build number did not change. I download the following file:
mozilla-win32-installer 18-Dec-2003 17:34 11M....
I downloaded a very current installer (an hour ago) and it worked for me...
That should be the one, or one from tomorrow (or later) would work too, if you
wait for that.
Build ID:2003121808 worked for me! THANKS!!
Alright, thanks for testing again and reporting back. Marking VERIFIED based on
above comments.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: