Closed Bug 118563 Opened 23 years ago Closed 19 years ago

The new print properties dialog does not save papersize

Categories

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

Product:
Core
Component:
Printing: Output
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.8beta4

People

(Reporter: marcus, Assigned: masayuki)

References

Details

(Keywords: fixed1.8)

Attachments

(1 file, 7 obsolete files)

fix for saving to pref on toolkit rv2.0
4.50 KB, patch
mconnor
: review+
asa
: approval1.8b4+
Details | Diff | Splinter Review 
The new print properties dialog in Mozilla versions 0.97+ has three
"misbehaviours" with the pagesize:

1. The default printer on my system uses papersize "A4" instead of "letter",
because here in germany we use this papersize. Mozilla ignores the setting of
the default printer and always uses "letter", so I have to change this manually.
2. When I change the papersize settings for mozilla, I have to change it for
printing mails and for printing webpages. This does not make sense, because I
don't know anyone who uses different printers for both mails and webpages.
Changing one setting should have effect on the other.
3. When I change the papersize for both mails and webpages and exit Mozilla, I
expect this settings to be permanent, but Mozilla turns the settings back to
"letter" instead of "A4".
doesn't save print orientation either
Status: UNCONFIRMED → NEW
Ever confirmed: true
dup of bug 83750 ?
I don't think so, because before the settings dialog was introduced, the print
settings where equal to the settings of my default printer, now it seems that
Mozilla comes along with it's own default settings and uses this settings
instead of my default settings of the printer.
On a laser printer this is really bad, because whenever I print a page without
changing the papersize from letter to A4, the printer tells the user to insert
paper with size "letter" and blocks all other users in the print queue. This
must not be.
Point 1. of my bug description must be fixed. When 1. is fixed, 2. and 3. are
not really bad, because Mozilla uses the changed settings for the whole session,
that should be enough.
We will be moving the Page Size out of the PageSetup and back into the
"Properties" dialog. On Windows that will be a native dialog, on Linux it will
be the XPDialog

As for the permanence of the the page size setting, that is a front end issue
and a separate bug should be filed.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0.1
*** Bug 119791 has been marked as a duplicate of this bug. ***
"Page Size" is out of the PageSetup and back into the "Properties" dialog, but
the non-persistent papersize bug is still there.

The problem I have is that the current summary for this bug describes exactly
this problem, so why must we open another one ?

Do you want to open another bug rod, because it's not up to you to solve it ?
Can you give us a name of whom to assign this to, if we really need to open a
new bug ?
Checking under Linux with 2002011708.

In the "Properties" dialog, the "Paper Size" selection is not persistent.

In "Page Setup", none of the settings is persistent.

This is cross-platform.

Like the man says, why the heck isn't Mozilla picking up the default settings
from Windows?  Or whatever OS it is running under?  Or just using them, and not
setting them itself?  This is very, very annoying (especially when your
workgroup printer requires manual intervention to print the job!)
You are right. I now have to change paper size settings for any mail I print
(and this could be many some days). This bug makes Mozilla nearly unuseable for
me and any other people not using the Mozilla defaults on their
workgroup-printer. Although I am really waiting for Mozilla 0.97 because of the
file-bug in forms, I don't think I will use Mozilla 0.98 if it wont be fixed.
This makes 0.98 a really bad milestone!
This really is a major pain and it being set as needing to be fixed by 1.0.1 is
not good and needs to be given an earlier target, 0.99 for instance. Would it
have a higher priority if it always had a paper size of A4 and for some people
to print off they had to select Letter?
One thing that I thought about this bug, but did not report immediately as I
thought the bug might get fixed fast.

For this sort of thing, the default value can not be hard coded inside Mozilla,
or that would mean it's impossible to change the default value for any
localization of Mozilla, wich would be very, very bad design.

So this value has to be coming from some localisable part of Mozilla, hence can
be changed without compilation.

I did succeed to make A4 the default choice under linux, but the way I did that
was not very clean (I had to remove in a .js the letter choice from the listbox
where you choose the paper size) and not applicable in windows (the control is
system drawn).

Removing the "letter" choice inside printPageSetup.properties (which sounds like
a reasonable place for this setting, and is the only one place where I can find
a reference to the "letterSize", "a4Size" values used by the above .js in the
tree), changes nothing under Windows and gives a blank default value under Linux.

So :
 - either the "letter" value is hard-coded somehow, and this is really bad.
 - either I haven't been able to find where to patch the javascript.

Adding this to pref.js :

user_pref("print.use_native_print_dialog", true);

solves the problem for me with 2002011703, A4 is the default value again, even
if the appearance of the dialog does not change much.

I got the idea to test that from reading the description of bug 118086
(discovering that bug let me understand why rods is not working much on 118563),
and then the patch in bug 122530. 
Well in fact, I first thought what I needed was
print.use_native_print_dialog=false and that that it would give me back the old
properties dialog, but I won't try to understand what's happening.

If I'm correct, print.use_native_print_dialog=true is now the default value on
the tree since the check in of bug 122530.

Adding user_pref("print.use_native_print_dialog", true); to my prefs.js does not
change the behaviour in build 2002013103, letter is still the default papersize.
The only thing, that changed is, that now the change of the pagesize stays
persistant for the whole session in Mozilla, but when I quit Mozilla and start
it again, "letter" is the default papersize again.
And: When printing a mail in the messenger, the print dialog is placed in the
lower right corner. It is placed so low, that the buttons at the bottom of the
dialog are invisible. For every mai lI print I have to change position of the
dialog. Why isn't it placed in the middle of the screen? Really bad.
On my system the setting user_pref("print.use_native_print_dialog", true); is
deleted from prefs.js any time I start the latest Mozilla build. This seems to
be why this setting does not have any affect on my system.
Yes, I've got the same behaviour as the two of you wih 2002020103.
user_pref("print.use_native_print_dialog", true); seems to be now the default
value and therefore deleted when prefs.js is saved.
The dialog comes up as "letter".

So guess what I did ? :-) (and it worked, of course)

No idea, really ?

Come on, what is the most twisted idea I could have had ?

...


I inserted in prefs.js :
user_pref("print.use_native_print_dialog", false); 

Once again, nothing changes in the appearance of the dialog, but A4 is back as
the default choice.
Hm. I tested this with build 2002020106. Now it is inverse:
user_pref("print.use_native_print_dialog", false); does not work, it shoes (as
expected) not the native dialog but the new, buggy dialog with "letter" as
default. When quitting Mozilla, the entry in prefs.js is deleted. 
But: Now user_pref("print.use_native_print_dialog", true); works as described by
 Jean-Marc Desperrier. I get the old windows dialog with A4 as default
papersize. This did not work with the build of the previous day. Seems to me, as
if the behaviour is getting inverse every day. Really strange.
Made a new bug (bug 123967) "should use system default paper size" for the fact
that it defaults to letter regardless of the system default.

Suggest leaving this bug (bug 118563) for saving what the user changes paper
size to in the dialog box (i.e. make user changes sticky) as the summary suggests.
This bug seems to depend on bug 123554, which will allow Mozilla to get the
print settings from Control Panel | Printers | {a printer} | properties.

Once that bug is fixed, Mozilla | File | Print | Properties should start with
the default values from the OS, and remember any changes made to print settings
within the same Mozilla session.

Setting this bug to depend on bug 123554, althought I'm not totally sure that's
right.
Depends on: 123554
This is just fscked up. 

Exactly the kind of behavior you get from academica, "we'll fix it someday"
attitude is not good enough for something many people use every day many times..
And really screws things up. Yeah, it works stateside. But nowhere else.

Okay, gentlemen, you should put the user_pref into user.js, NOT prefs.js.
user.js is persistent and meant for your personal preferences.
With my build (2002020908), 
user_pref("print.use_native_print_dialog", true);
in user.js makes things work as you'd expect it to. How about making that pref
*default* starting, say, tonight? 

Change it back to the new and "improved" dialog *WHEN IT'S FIXED*, not make
everyone wait with the broken dialog by default until xmas. 

Harrumph.
Hmmm, it doesn't WFM in a build from source 24 hours ago (W2K-SP2). OK, it uses
the native Windows print dialogue, but doesn't save the paper size, it reverts
to Letter each time.
Oops.

I checked my user.js and the correct setting is: 

user_pref("print.use_native_print_dialog", false);

.. With that, I get this custom print dialog, but the properties screen uses
whatever's my system default.
Olli,

Have you checked out Edit->Preferences->Debug? There's a nice little checkbox
there for native print dialog. You don't need to go messing in user/prefs.js
Olli,

Yep, that WFM.

Thanks.
so can we mark this bug RESOLVED-WORKSFORME ? or do we still have issues.
We cannot mark this "worksformerly", because the new dialog has still the bug.
The only thing that works formerly is switching back to the old dialog, which
does not fix the bug in the new dialog itself!
Well, I don't want to mess with prefs.js in any case. 
I mean, next time you restart that gets overwritten. user.js is still there for
your grandchildren to see..

In any case! 
checking
Edit->Preferences->Debug->Use native print dialog
seems to work. Cool. I still didn't see anyone mention that before. That
basically does what my user.js hack does.

So now get off your **** and fix the default..? 
*** Bug 125187 has been marked as a duplicate of this bug. ***
Blocks: 125824
I think all the issues here have been resolved by other bugs.
It still doesnt save the paper size for me.  If I go file->print click on
properties, change papersize from letter to DIN A4, then print something, then
exit mozilla, next time I open mozilla and go to print something, papersize is
back to letter.
Try enabling native print dialog from Debug-settings. If it's enabled, try
disabling it. One is broken.
Priority: -- → P1
Target Milestone: mozilla1.0.1 → Future
The solution with Native Print Dialog doesn't work in Solaris. (There is no
Native Print Dialog there.) The bug should be fixed.
*** Bug 127401 has been marked as a duplicate of this bug. ***
This Bug is on Linux too
OS: Windows 2000 → All
Hardware: PC → All
*** Bug 129434 has been marked as a duplicate of this bug. ***
*** Bug 129682 has been marked as a duplicate of this bug. ***
*** Bug 129683 has been marked as a duplicate of this bug. ***
we're getting so many DUPs on this...nominating...
Keywords: nsbeta1
This will be fixed by Bug 128142
Depends on: 128142
*** Bug 129886 has been marked as a duplicate of this bug. ***
*** Bug 130227 has been marked as a duplicate of this bug. ***
OK, this bug makes me go mad! With Milestone 0.9.9 everything is fine with
"native print dialog" when I print some pages in the browser. Papersize is A4 as
it should be.
But: When I try to print a mail in the Mail/News-Client, the native print dialog
again gives me "letter" as default papersize and not "A4" as it should. I tried
the debug option "global print settings", but this has no effect.
And: when I press the "print" button in the mail client and exit the native
print dialog via "cancel", and then press the "print" button again, Mozilla
seems to do something, but I get no print dialog. Hm. Not so good.
Perhaps this is of some help to the developers: 
In previous releases of Mozilla (0.9.4 for sure) the default paper size could be
set in the /usr/local/mozilla/default/prefs/unix.js or in the user's user.js
file with the print.print_paper_size pref setting.
Now, with version 0.9.8 this setting does not seem to work anymore.
I tested some other prefs, the print.color pref for instance still works.
Maybe this is causing the problem.

Is there any way I can set the default paper size for Mozilla 0.9.8 and up under
Linux?
*** Bug 130863 has been marked as a duplicate of this bug. ***
*** Bug 131451 has been marked as a duplicate of this bug. ***
OK, I have tried all possible combinations of 

 * Edit->Preferences->Debug->"Use Native Print Dialog"
 * user_pref("print.use_native_print_dialog",[true|false]) in user.js
 * pref("print.print_paper_size",$n) in unix.js

Whatever I do, the paper size gets reset to "Letter" everytime I restart Mozilla.

SORT THIS OUT! A simple tickbox in the print preferences with "Make this my
deafult print setting" would do! Anything! You are **** off the entire
European userbase
On behalf of all the developers working for *free* on the Mozilla project, and
as an open-source developer myself, I'd like to remind John that anyone "****
off" with Mozilla is free to pay for Opera, or (gasp) even use IE. Let's be
nice, OK?
Or more usefully, help to fix the bug....
OK, change "you are **** off the entire European userbase" to "the entire
European userbase are **** off". My frustration is genuine, but I appreciate
that it is not constructive to just go around finger pointing.

bzbarsky: comprehensive testing is the first step to fixing. That is how I am
best able to help.
On Linux it should work now. And you can set the default paper size by _name_
(the integer-value nightmare is gone), too.

Here's an honest but naive question: is there enough time to fix this bug on
Win32 for 1.0?
I just tested this on Linux, it now works from Roland's check in
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Keywords: nsbeta1
Resolution: --- → WORKSFORME
What about the other platforms?
This works on Linux
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Not sure it will get fixed for Mac and on Windows it does pick up ther default
paper size from the printer, but it doesn't save it out and remember it.
Status: REOPENED → ASSIGNED
*** Bug 133680 has been marked as a duplicate of this bug. ***
It does work (nearly) perfectly with Build 2002032707 on FreeBSD4.4.

1. "Page Setup"
read "Margins(inches)" instead of "Margins(millimeters)"

2. "Printer Properties"
"Gap from edge of paper to Margin(inches)" has no effect, but is saved on exit.

3. Header/Footer position is determined alright by lines
``pref("print.print_edge_top", 30);'' et cetera
in file /usr/local/mozilla/defaults/pref/unix.js

4. Fortunately, bug #129653 has again disappeared in this build, so I can fully
use it. But something must be wrong there which makes bug #129653 come and go.
There is no reaction from the person whom the bug is assigned to.
What can we do ?


*** Bug 134373 has been marked as a duplicate of this bug. ***
Blocks: 134373
No longer blocks: 134373
*** Bug 134373 has been marked as a duplicate of this bug. ***
*** Bug 135393 has been marked as a duplicate of this bug. ***
Here are my observations on Linux:

The settings are saved if you change the papersize to A4, click OK in the
Properties dialog AND after that press Print.

The settings are NOT saved if you change the paper size to A4, press OK in the
Properties dialog and then cancel your printing.

What if I don't want to print, but just setup the papersize correctly?

Should I file a separate bug on that?
I should add that the settings are saved *in this session* in the second step,
but not after a shutdown. That's why I consider it a bug.
André Dahlqvist wrote:
> Should I file a separate bug on that?

AFAIK canceling the main print dialog should undo all changes made, even those
in the print job options dialog. Feel free to file a bug for the issue and
assign it to me, please...
Filed bug 135442 on that issue.
This is a *big* deal for almost all non-US/CA users not just Europe (and Japan). 

It makes Printing a very frustrating experience when your paper size is not
correctly set and this was one of the major annoyances with badly
internationalised software in the past - so much so that some workgroup printers
have an option to print Letter as A4. Anyone who has had to press Continue
repeatedly while PC LOAD LETTER flashes on the Printer LCD will appreciate this.

In addition the inconsistent behaviour between the Browser and Mail & News print
is doubly frustrating. 

We should fix this for 1.0

Observed on Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2)
Gecko/20020506


See: http://www.cl.cam.ac.uk/~mgk25/iso-paper.html
"The United States and Canada are today the only industrialized nations in which
the ISO standard paper sizes are not yet widely used"

*** Bug 144342 has been marked as a duplicate of this bug. ***
Andre, I think the solution for this is Bug 137089. It needs an apply button.
Actually, that won't do it, we need a new bug. One for requesting an Apply
button on the "Properties" dialog.

The Apply would set it into the PrintSettings AND save them out to prefs.
filed bug 144530 for apply button on print props dialog 

whoever wants to cc: themself on that bug can do so by going
there and adding yourself to that new bug.

Rod, what do you want to do about this bug ?
The paper size is saved if you press OK on the Prop dialog and OK on the print
dialog. (on Linux)
On Netscape 7 PR1 Paper size *always* defaults to letter if print dialog is
invoked by javascript:window.print(), Composer or, Mail Compose window.

Paper size changes are *never* saved; even if the print dialog is invoked
immediatley after the paper size is changed.

Normally a user wants to set the paper size once for an entire application and
ideally the default paper size should be read from system perferences. 

Since the majority of the world does not use Letter as the default paper size if
we must default to something perhaps we should be defaulting to A4 instead.
I should add that this is the same on Mozilla 2002-06-04-17-1.0.0
What about a trunk build? On the trunk once the paper size is set it remains the
same. I don't have a linux branch build to test this. Maybe some fixes haven't
been checked into the branch that need to be.
OK. It is working correctly on Windows 2002-06-05-04-trunk

In fact on the trunk build in a new profile it set the paper to A4 by default.
Great work!
Since these fixes did not make it into Mozilla 1.0 can we nominate them for 1.0.1?
Keywords: mozilla1.0.1
*** Bug 164601 has been marked as a duplicate of this bug. ***
Can this bug be marked as DUPlicate of bug 166217 ("Print settings on Linux are
saved at shutdown but not read at next start") ?
Roland, I don't think, this here is a dupe of bug 166217. Firstly, this one here
is much older, secondly, this is OS=ALL, thirdly, see comment 3. The latter
suggests, that bug 166217 might be a dupe of bug 83750.

Another question is if bug 83750 blocks this bug here.

pi
Depends on: 83750, 166217
*** Bug 185491 has been marked as a duplicate of this bug. ***
*** Bug 169183 has been marked as a duplicate of this bug. ***
This bug does not exist in version 1.2.1
Bug 185491, which was marked a dup of this one, was not only about paper size
but included not saving the default print command under Linux which reverts to
lpr ${MOZ_PRINTER_NAME:+'-P'}${MOZ_PRINTER_NAME}

That fault also did not exist in Ver 1.2.1 and does in 1.3
(The corruption of prefs.js that I reported in bug 185491 is fixed)
*** Bug 198207 has been marked as a duplicate of this bug. ***
I'm using 2 "duplex" HP Laser printers (HP-4500 & HP-8000) here for daily work,
as stated the Print Properties are not persistant. Most anoying to me besides 
the print quality or margins setting is the "Print on Both Sides" duplex option
is not persistant from the browser or email client. Also, please see my notes on
updating the Print UI...

Bug 181527 - Printing always prints full header
http://bugzilla.mozilla.org/show_bug.cgi?id=181527#c17

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030612
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4)
Gecko/20030612
Some additional information on print setting persistancy for duplex printers. I
got an error the other day indicating I needed certain "Administrator" rights to
make or change printer default settings and behavior using XPpro Sp2. If it
happens again I'll try to do a screen shot save the exact error message.
This bug is still/again present in the 1.6 release. And as other people have
mentioned very annoying.
*** Bug 243012 has been marked as a duplicate of this bug. ***
*** Bug 242931 has been marked as a duplicate of this bug. ***
Flags: blocking1.8a2?
Hi all,

I entered this bug some weeks ago as # 242931 - well it is at least a triplicate. 

In general: What is so diffcult in fixing this nasty and annoying bug that it
cannot be fixed in nearly THREE years???? In this bug report are more than a
dozen of entries which declare other bug reports as similar or duplicate.
Somehow this bug seems to be of the "Microsoft" type with his life span.

For myself I feel it very disappointing to stand in front of our workgroup
printer and have to confirm printing of each! individual page in the letter
format. And if I don't do this the complete que is blocked.

And to all people thinking like "Who cares about this problem with the A4
format?": By far the most users (I guess 10 to 20 times) reside outside the
tight borders of "letterland" and have to use different sheets. I don't want to
get political but it taste a little bit like "There is no life outside the
states." But we are alive... :-) 

So please go on now and fix this eternal bug in a reasonable time instead of
introducing new features!

Andy

Try the following in your user.js:

// Print on A4 paper
user_pref("print.postscript.paper_size", "A4");

pi
Well said.

How many votes does it take?

How much time does it take?
Flags: blocking1.8a2? → blocking1.8a2-
Is it possible to make this bug a blocker? 

I really think that releasing a product that stuffs around with your user's
printer settings is not really the kind of user experience people should have. I
have installed firefox on many of my friend's computers, and most of them get
this problem. Worse, most of them don't even know how to change the paper size
as they have never had to. 

Andi Voss - nicely said.

BTW, I think bug 255007 is a duplicate (what number are we up to now with
duplicates?).

Sam


*** Bug 255007 has been marked as a duplicate of this bug. ***
SUMMARY:
On US W2k, IE6 behaves the same way.
  Does not change to A4 unless 'print' clicked, even if 'apply' clicked.
  Setting persists within session.
  Reverts to previous setting when application (IE6) is restarted.

But can change the defaults at the operating system level.
  Start | Settings | Printers | context-click printer | Printing Preferences

DETAIL:
On US W2k, it appears that IE6 behaves the same way:
  Start | Internet Explorer

    IE6:
    File | Print...

      Print:
      Paper/Quality | Advanced...
      
        Advanced Options:
        Paper output:
          Paper size: A4 (change, was letter)
        click 'OK'

      click 'Apply'.

      Paper/Quality | Advanced...

        Advanced Options:
        Paper output:
          Paper size: A4 (verify changed)
        click '	OK'

      click 'Cancel'

    File | Print...

      Print:
      Paper/Quality | Advanced...

        Advanced Options:
        Paper output:
          Paper size: A4 (was 'letter' again due to cancel)
        click 'OK'

      click 'Print'

    File | Print...

      Print:
      Paper/Quality | Advanced...

        Advanced Options:
        Paper output:
          Paper size: A4 (verify change persisted)
        click 'OK'

      click 'Cancel'

    File | Close

  Start | Internet Explorer

    IE6: 
    File | Print...

      Print:
      Paper/Quality | Advanced...
      
        Advanced Options:
        Paper output: Paper size: letter (became 'letter' again due to close)

      click 'Cancel'

    File | Close

Can change the default at operating system level:
  Start | Settings | Printers

    Printers: 
    right-click printer | Printing Preferences

      Printing Preferences:
      Advanced...

        Advanced Options:
        Paper/Output:
          Paper Size: A4 (change, was letter)
        click 'OK'
 
      click 'OK'

    File | Close

  Start | Firefox

    Firefox
    File | Print...

      Print:
      Select same printer as above
      Properties...
      
        Document Properties:
        Advanced...

	  Advanced Options:
	  Paper output:
            Paper size: A4 (verify now changed!)
	  click 'OK'

        click 'OK'

     click 'OK'

Does this help?
Hi,

I´m fighting with this bug, too. This is my expirience: We are using Mozilla
.16.x and 1.7.x at several WindowsXP-PCs. The operatingsystemdefault for the
paper is A4, and printing from Mozilla works. But when an user gets an us-letter
word-document, sometimes the os-default changes to us-letter. Mozilla seems to
recognize this. I changes the os defaults and printer defaults back to A4, and
any application prints A4 again, but mozilla and firefox 1.0 keep using us
letter. I uninstalled mozilla, deleted the mozilla-folder and the
user_pref-file, installed firefox, but the bug is still there. Some
laserprinters ignore the bug and print the letter printjob automatically on an
A4sheet, but several printers will be blocked by firefox. Because of security
reasons, I tell the people not to use MS IE, but firefox, but with this bug it
ist difficult.

Regards

sigi
With version 1.7.5 (in fact sometime around 1.7) the situation has improved a
little, although I see no mention about that in this bug.

When the default print properties for the (Windows) user have been set to
papersize A4, and I press the print icon or select Print... from the menu, it
works OK!  A4 papersize is used, also for the formatting (so there is no 3-cm
bottom margin on the printouts, as happens when you set your printer to "use A4
when LETTER is requested", a non-solution IMHO).

However, when the page has a Javascript window.print call it still uses the
LETTER format for the page!  So the printer displays "Load LETTER" and requires
a confirmation to continue.

re: window.print in comment #95, that is bug 156992 which has been fixed but
that fix didn't go into 1.7.5, so if you live outside "letterland" (comment 88)
you'll have to wait for suite 1.8 or firefox 1.1 to use the print button on webpages

*** Bug 278941 has been marked as a duplicate of this bug. ***
*** Bug 280407 has been marked as a duplicate of this bug. ***
*** Bug 255960 has been marked as a duplicate of this bug. ***
> re: window.print in comment #95, that is bug 156992 which has been fixed but
> that fix didn't go into 1.7.5, so if you live outside "letterland" (comment 88)
> you'll have to wait for suite 1.8 or firefox 1.1 to use the print button on
webpages

That was written in late 2004, so if the bug was already fixed back then, why is
it still in the brand-new Firefox 1.02?

This bug has been there since Netscape 6.00, and it still resides in the latest
Firefox. Is the community unwilling or unable to fix it within so many years?
Keeping bugs over years and several major product versions is Microsoft style.
It surprises me to find the same stance here as well.
(In reply to comment #100)
As the text you've quoted says, the fix is in and will be part of Firefox 1.1 or
Moz Suite 1.8. Unfortunately neither of those have been released yet.

Firefox 1.02 was just a bug and security fix release for Firefox 1.0, it is
based on Firefox 1.0 which is based on a version of Gecko/Mozilla nearly a year
out of date with the main development of Mozilla/Firefox at the moment. It was
not a full version release, that will be Firefox 1.1.

In the mean time if you're a non-Letter user (like me, I live in A4-land) then
your best bet is to download a Mozilla 1.8 beta release, or if you're willing to
take the risk you can try downloading a pre-alpha version of firefox 1.1.
However neither of these are full releases and are not going to be as reliable
as waiting for FF 1.1.
Workaround in comment 89.

pi
*** Bug 281095 has been marked as a duplicate of this bug. ***
*** Bug 293980 has been marked as a duplicate of this bug. ***

        Attachment #184781 -
        Flags: review?(jshin1987)

    
    

    
  
Comment on attachment 184781 [details] [diff] [review]
fix for default setting on Windows

Oops..
This patch doesn't complete to fix this bug.
But it sets the first setting as printer's default setting.

        Attachment #184781 -
        Attachment description: fix on Windows → fix for default setting on Windows

    
    

    
  
Masayuki, do you want to make a new patch to fix the problem or do you want me
to review the current patch that takes care of the obvious mistake of using
UTF-8 when calling Windows A APIs? I wonder how many bugs like this are in our
code....
Assignee: rods → masayuki
Status: ASSIGNED → NEW

    
    

    
  
I want your review for current patch.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        fix for saving to pref (obsolete)
        — 
          — Splinter Review
      

    


  

        Attachment #184821 -
        Flags: review?(mconnor)
Status: NEW → ASSIGNED

    
    

    
  

      
      
      
      

        Attached patch
          
          
        fix for saving to pref on suite (obsolete)
        — 
          — Splinter Review
      

    


  

        Attachment #184826 -
        Flags: superreview?(neil.parkwaycc.co.uk)

        Attachment #184826 -
        Flags: review?(neil.parkwaycc.co.uk)

    
    

    
  
Comment on attachment 184826 [details] [diff] [review]
fix for saving to pref on suite

I can't review this because I can't duplicate the bug.

Shouldn't you check gPrintSettingsAreGlobal && gSavePrintSettings ?

        Attachment #184826 -
        Flags: superreview?(neil.parkwaycc.co.uk)

        Attachment #184826 -
        Flags: superreview-

        Attachment #184826 -
        Flags: review?(neil.parkwaycc.co.uk)

    
    

    
  


  
Neil:

If you can test on Windows or Mac, please test on the system.
This problem is not reproduced on Linux. Because Linux using XP Print Dialog
that is write the pref.

        Attachment #184826 -
        Attachment is obsolete: true

        Attachment #184845 -
        Flags: superreview?(neil.parkwaycc.co.uk)

        Attachment #184845 -
        Flags: review?(neil.parkwaycc.co.uk)
Flags: blocking1.8b3?
Target Milestone: Future → mozilla1.8beta3

        Attachment #184821 -
        Flags: review?(mconnor)

        Attachment #184821 -
        Attachment is obsolete: true

        Attachment #184846 -
        Flags: review?(mconnor)

    
    

    
  


  
When javascript:widnow.print(), the print process ignore the prefs in current
code.
We need to fix it.

        Attachment #184848 -
        Flags: review?(jst)

    
    

    
  
Comment on attachment 184781 [details] [diff] [review]
fix for default setting on Windows

r=jshin

        Attachment #184781 -
        Flags: review?(jshin1987) → review+

        Attachment #184781 -
        Flags: superreview?(bzbarsky)

        Attachment #184781 -
        Flags: superreview?(bzbarsky) → superreview+

        Attachment #184781 -
        Flags: approval1.8b3?

    
    

    
  
Comment on attachment 184781 [details] [diff] [review]
fix for default setting on Windows

a=shaver

        Attachment #184781 -
        Flags: approval1.8b3? → approval1.8b3+

    
    

    
  
checked-in: "fix for default setting on Windows"

        Attachment #184781 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 184848 [details] [diff] [review]
make the same as suite/toolkit print process for "javascript:window.print()" rv1.0

r+sr=jst

        Attachment #184848 -
        Flags: superreview+

        Attachment #184848 -
        Flags: review?(jst)

        Attachment #184848 -
        Flags: review+

        Attachment #184848 -
        Flags: approval1.8b3?

    
    

    
  
Comment on attachment 184848 [details] [diff] [review]
make the same as suite/toolkit print process for "javascript:window.print()" rv1.0

a=chofmann

        Attachment #184848 -
        Flags: approval1.8b3? → approval1.8b3+

    
    

    
  
(In reply to comment #112)
>If you can test on Windows or Mac, please test on the system.
>This problem is not reproduced on Linux. Because Linux using XP Print Dialog
>that is write the pref.
Can you show me where? Thanks.

    
    

    
  
(In reply to comment #120)
> (In reply to comment #112)
> >If you can test on Windows or Mac, please test on the system.
> >This problem is not reproduced on Linux. Because Linux using XP Print Dialog
> >that is write the pref.
> Can you show me where? Thanks.

Sorry. I cannot understand this comment well.

Step for reproduce(Win or Mac):
1. Show about:config
2. if you can show the prefs that name is "print.printer_<printer
name>.paper_size", keep the value in your mind.
3. Print any page by using [File] -> [Print...] and you change the paper size.
4. Show about:config again.

You can show "print.printer_<printer name>.paper_size" is changed (or created)
by my patch.

    
    

    
  
Comment on attachment 184845 [details] [diff] [review]
fix for saving to pref on suite rv2.0

OK, I was able to reproduce the problem now.

Is there code in the XP print dialog that's now redundant?

        Attachment #184845 -
        Flags: superreview?(neil.parkwaycc.co.uk)

        Attachment #184845 -
        Flags: superreview+

        Attachment #184845 -
        Flags: review?(neil.parkwaycc.co.uk)

        Attachment #184845 -
        Flags: review+

    
    

    
  
> Is there code in the XP print dialog that's now redundant?

Maybe.



        Attachment #184845 -
        Flags: approval1.8b3?

    
  

        Attachment #184845 -
        Flags: approval1.8b3? → approval1.8b3+

    
    

    
  
checked-in "fix for saving to pref on suite rv2.0" and "make the same as
suite/toolkit print process for "javascript:window.print()" rv1.0"

        Attachment #184845 -
        Attachment is obsolete: true

        Attachment #184848 -
        Attachment is obsolete: true

    
  
Flags: blocking1.8b3? → blocking1.8b3-

    
    

    
  


  
Don't know if you guys can fix this cosmetic issue while you're here or not but
it's as follows:

Click File-> Page Setup and change the page orientation format by selecting
either Portrait or Landscape. Clicking between the two you should notice that
the tab panel animates. Doing so changes the height of its surrounding group
box which affects the height of the tab panel. The result is a tab panel which
jumps up and down.

    
    

    
  


  
Don't know if you guys can fix this cosmetic issue while you're here or not but
it's as follows:

Click File-> Page Setup and change the page orientation format by selecting
either Portrait or Landscape. Clicking between the two you should notice that
the tab panel animates. Doing so changes the height of its surrounding group
box which affects the height of the tab panel. The result is a tab panel which
jumps up and down.

    
    

    
  
Bryan:

It's not related this bug.
Please file a new bug.

        Attachment #187215 -
        Attachment is obsolete: true

        Attachment #187217 -
        Attachment is obsolete: true
Flags: blocking-aviary1.1?

    
    

    
  
(In reply to comment #127)
>Please file a new bug.
IIRC the orientation jiggle bug has already been filed.

    
    

    
  
(In reply to comment #128)
> (In reply to comment #127)
> >Please file a new bug.
> IIRC the orientation jiggle bug has already been filed.

Neil, it has not been fixed.  Maybe you're referring to bug
https://bugzilla.mozilla.org/show_bug.cgi?id=137091 in which you reviewed a
patch?  if you click on the attachment I submitted above "Changing page
orientation causes tab panel to "animate"." you'll see what i'm talking about. 
This still occurs in the latest builds:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050624
Firefox/1.0+ ID:2005062413


    
    

    
  
(In reply to comment #129)
>(In reply to comment #128)
>>(In reply to comment #127)
>>>Please file a new bug.
>>IIRC the orientation jiggle bug has already been filed.
>Neil, it has not been fixed.  Maybe you're referring to bug 137091
I said fiLed, not fiXed, but I see you found the relevant bug.

    
  
Flags: blocking1.8a2-
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1-

        Attachment #184846 -
        Flags: review?(mconnor) → review?(bugs)
Target Milestone: mozilla1.8beta3 → mozilla1.8beta4
Flags: blocking1.8b5?
Flags: blocking1.8b4?
Whiteboard: [needs review ben]

    
  
Flags: blocking1.8b5?
Flags: blocking1.8b4?
Flags: blocking1.8b4+

        Attachment #184846 -
        Flags: review?(bugs) → review+
Whiteboard: [needs review ben] → [needs approval]

    
    

    
  
Comment on attachment 184846 [details] [diff] [review]
fix for saving to pref on toolkit rv2.0

The risk is low. If this is checked-in, Firefox and Thunderbird become the same
as Seamonkey and JS printing.

        Attachment #184846 -
        Flags: approval1.8b4?

    
    

    
  
checked-in to Trunk.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 19 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.8beta4 → mozilla1.9alpha

    
  

        Attachment #184846 -
        Flags: approval1.8b4? → approval1.8b4+

    
    

    
  
checked-in to branch too.

Thank you everyone!
Keywords: fixed1.8
Whiteboard: [needs approval]
Target Milestone: mozilla1.9alpha → mozilla1.8beta4

    
    

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

    
    

    
  
What is this? Does it have no bug number?

I think that we cannot remove those settings in only toolkit or only xpfe.
Because these settings are used on Gecko(for "javascript:window.print();").
If we hope that these settings are removed, we should remove completely from
toolkit, xpfe and Gecko.

If we need to remove these settings, please file a new bug. This bug's patch are
made like Gecko's process.

    
    

    
  
No, there was no bug number, and Pierre is no longer around. I'm not saying that
adding them back in is a bad thing, I was just wondering why they were removed
in the first place. We might never know! ;)

    
    

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

    
    

    
  
This may be the same bug as reported yesterday (Bug 318356), but it's certainly not resolved.  I recently updated to Firefox 1.0.7 and the problem is still there!  Symptoms are just the same.

In the Keywords field of this bug it says 'Fixed 1.8'.  As I've said, it's not fixed, but what is the '1.8'?

PLEASE REOPEN THIS BUG.  It's been going on for years.  Isn't it about time it was fixed?

    
    

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

    
    

    
  
(In reply to comment #139)
>In the Keywords field of this bug it says 'Fixed 1.8'.  As I've said, it's not
>fixed, but what is the '1.8'?
This bug is in the Core product. Core product versions are roughly:
1.7: Firefox 1.0.x (obsolete, use Firefox 1.5 instead)
1.8: Firefox 1.5 plus possibly future versions (1.6, 2.0?)
Trunk: Unspecified future versions of firefox

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: