135361 - Print properties margin callouts mislabeled

Status: VERIFIED FIXED

(Core :: Printing: Output, defect)

Description

[John Cirillo]

Haven't seen this mentioned yet, but since 0.9.9 and to the present (20020403)
when you click on Print, then Properties, you have top/bottom/left/right. But
since I needed to diddle with them to get it to look right, I must have used up
half a ream of paper before understanding that these are mislabeled.

Here is the map:

Top=Top
Bottom=Left
Left=Right
Right=Bottom

And when you set these, then look in the prefs.js, you'll see that what you
thought was bottom got assigned to left, etc. Pretty maddening.

By the way, as of 20020403 these buttons don't work at all. I suppose this is
temporary. Although it is saving the values, nothing changes when I print.
These new settings, like
user_pref("print.printer_PostScript/default.print_edge_bottom", 1)
seem to be ignored. And the bottom footer has crept up, currently hard wired to
about .6 inches.
The old settings, such as
user_pref("print.print_edge_right", 20);
will still work when I add them back in, but have to be hand-edited. All except
for the bottom. Can't make it go down below 0.6 inches.

Comment 1

[Boris Zbarsky [:bzbarsky]]

To Roland.  This broke as a result of the patch in bug 132563, which has gems like:

      i = dialog.bottomInput.value * 100;
      gPrefs.setIntPref("print.printer_"+printerName+".print_edge_left", i);

and 

    dialog.bottomInput.value =
      gPrefs.getIntPref("print.printer_"+printername+".print_edge_left") /
        100.0;

in the loadDialog() and onAccept() functions.

I suspect that another checkin of Roland's also introduced the
"printer_PostScript/default" stuff that broke these prefs recently.

Comment 2

[Roland Mainz]

OT: Does BugZilla have a bug ? I did not get any email that this bug was
assigned to me... ;-(

Comment 3

[Roland Mainz]

Boris Zbarsky wrote:
> I suspect that another checkin of Roland's also introduced the
> "printer_PostScript/default" stuff that broke these prefs recently.

Which prefs are broken (except those listed in comment #1) ?

"PostScript/default" is the printers name and I added the prefix "printer_" to
avoid any risk that people have printers with the same name as our prefs (should
not happen, but I want to be on the safe side in this case) ...

Comment 4

[Roland Mainz]

Attachment: Patch for 2002-03-31-08-trunk

Death to the germs! :)

Comment 5

[Roland Mainz]

Requesting r=/sr=/a= ...

Comment 6

[John Cirillo]

Did some more testing on this 20020403 build. Here are some results of what works
and what gets saved or not:
default.print_command works and saves
default.print_edge_x doesn't work but does save
in Page Setup > margins and headers/footers, these all work but do not get saves
Portrait, landscape, scale, work but don't get saved
Paper size, name, etc all appear to work and save out.

Not sure what the print.tmp.printerfeatures are for. 

Again, the old print.print_edge-x commands still work but have to be
added/edited by hand.

Hope this is not late news already. Roland, when will your patch get applied to
the builds? I will be glad to test this to the end. These headers/footers are my
pet obsession for some reason.

Comment 7

[Roland Mainz]

John Cirillo wrote:
> default.print_command works and saves
> default.print_edge_x doesn't work but does save
> in Page Setup > margins and headers/footers,
> these all work but do not get saves

Could you open single bugs for these issues, please ?

[snip]
> Not sure what the print.tmp.printerfeatures are for. 

That's the printerfeatures prototype (these options are actually a result of the
communication between the native code and the dialogs, however I forgot to set a
flag which says "do not save this stuff")... that will be fixed by bug 136058
("Implement nsPrinterFeatures"). The idea is quite simple - the printerfeatures
framework would allow an application to display only valid choices for a printer
(for example - no more the offer for DIN-A3 when the printer does not support
DIN-A3 etc.) ...

> Again, the old print.print_edge-x commands still work but have to be
> added/edited by hand.

This is the first time that I hear about this thing...

> Hope this is not late news already.
> Roland, when will your patch get applied to
> the builds?
> I will be glad to test this to the end. These headers/footers are my
> pet obsession for some reason.

Well... this depends all up on the detail whether I get r= (review), sr=
(superreview) and a= (approval) before 1.0 will be released...

Comment 8

[John Cirillo]

I will post the other problems as separate bugs per comment #7.
I installed 20020408, and the extra print.tmp.printerfeatures lines no longer
appear in prefs.js, by the way.

John

Comment 9

[Roland Mainz]

John Cirillo wrote:
> I installed 20020408, and the extra print.tmp.printerfeatures lines no longer
> appear in prefs.js, by the way.

Ugh. Noooo.... ;-(
Can you verify this, please ? I did not change this yet... and if the stuff is
missing then the printerfeatures code may not be working anymore... ;-(

Comment 10

[John Cirillo]

Hmm... OK, never mind. I started over with a new nightly and cleared everything
out. The print.tmp.printerfeatures are back.
No idea where they went before but it's ok now (again?)

John

Comment 11

[sujay]

marking WFM based on comments. REOPEN if still a problem.

Comment 12

[John Cirillo]

I think the real issue that this bug relates to is the incorrect labeling of
top, bottom, left and right callouts for the margins. As long as Roland's patch
gets implemented, I agree this issue will have been resolved.
(The other related issues have been posted as separate bugs.)
John Cirillo

Comment 13

[sujay]

verified.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Reopening.  There is a real bug and a patch and that patch has _not_ yet been
checked in.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 77886 [details] [diff] [review]
Patch for 2002-03-31-08-trunk

r=bzbarsky.  Let's hope we can land this on branch....

Comment 16

[Roland Mainz]

sujay wrote:
> marking WFM based on comments. REOPEN if still a problem.

Uhm... no... that discussion about printerfeatures was slightly offtopic :)

This bug is about mislabeled XUL widgets in the print dialog - and that is not
fixed yet... ;-(

Comment 17

[Marc Attinasi]

Comment on attachment 77886 [details] [diff] [review]
Patch for 2002-03-31-08-trunk

sr=attinasi

Comment 18

[Boris Zbarsky [:bzbarsky]]

Checked in on the trunk; leaving open for Roland to decide whether to pursue
approval for the branch.

Comment 19

[Roland Mainz]

Request for 1.0-branch approval is out - lets hope they will take it...

Comment 20

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 77886 [details] [diff] [review]
Patch for 2002-03-31-08-trunk

a=[e-mail] for branch checkin

Comment 21

[Randell Jesup [:jesup] (needinfo me)]

I'll be checking this into branch

Comment 22

[Randell Jesup [:jesup] (needinfo me)]

Checked in on branch for roland

Comment 23

[sujay]

John, can you verify this on the trunk? thanks.

Comment 24

[John Cirillo]

I've downloaded the nightly: 2002-04-26-10-trunk.
I confirm that the saved settings in prefs.js 
correspond with the callouts in the printer properties box.
That's all this bug is supposed to correct, and it does.
Thanks for the quick turnaround on this.
John

Comment 25

[sujay]

verified per comments.