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

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.

*** 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.

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. ***

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.

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

*** 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...

This will be fixed by Bug 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

What about the other platforms?

This works on Linux

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.

*** 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. ***

*** 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?

*** 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

*** 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. ***

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?

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. ***

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.

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....

I want your review for current patch.

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 ?

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.

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

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

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

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

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

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

(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?

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

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"

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.

(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.

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.

checked-in to Trunk.

checked-in to branch too. Thank you everyone!

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

Was this bug caused by: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=print&filetype=regexp&who=chanial%25noos.fr&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2003-11-01+17%3A21&maxdate=2003-11-01+17%3A21&cvsroot=%2Fcvsroot ? I guess that checkin was wrong?

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