129033 - Page setup selection in print preview does not update portrait/landscape buttons

Status: RESOLVED DUPLICATE of bug 311028

(Core :: Print Preview, defect)

Description

[Peter Lairo]

Mozilla/5.0 (Windows; U; WinNT4.0; de-AT; rv:0.9.8+) Gecko/20020304

Page setup selection in print preview does not update portrait/landscape buttons

Comment 1

[Andrew Hagen]

WFM Build ID: 2002031903 (0.9.9+) Windows 98.

I think this was fixed with a recent check-in.

Okay to resolve worksforme?

Comment 2

[sujay]

Peter does this work for you now in latest build? if so mark this WFM...thx.

Comment 3

[Peter Lairo]

No this still doesn't work.

1. in print preview notice that (e.g.) portrait button is depressed
2. click on "Page Setup..."
3. Change "Format / Orientation" to Landscape; then press OK

What happens:
4. Notice that toolbar button still has the *portrait* button depressed

What should happen:
4. The toolbar should be updated so that the *Landscape* button is depressed.

Comment 4

[Andrew Hagen]

Confirming on Build ID: 2002032203 (0.9.9+) Windows 98.

Comment 5

[rods (gone)]

Front-end issue, this is a dup

Comment 6

[rods (gone)]

taking

Comment 7

[rods (gone)]

back to sgehani

Comment 8

[Samir Gehani]

Rod,
Does your patch for the scale combobox fix this as well?

Comment 9

[rods (gone)]

yes, this is now fixed (or should be)

Comment 10

[Andrew Hagen]

This doesn't seem to be fixed yet in branch build ID: 2002050706, classic skin.

Comment 11

[Samir Gehani]

Andrew,
I don't think Rod has checked in his patch for the scale combobox.

Comment 12

[rods (gone)]

I have not checked this in on the Branch yet - bummer maybe I'll get permission
soon.

Comment 13

[Chris Smith]

Sounds like this might be related to my problem with rc3 on linux - when I
select Landscape mode for printing, the page prints in portrait mode and the
page setup dialog reverts my setting to Portrait mode.

Comment 14

[Louie Zhao]

This problem only exits on Windows platform because there is no 
"portrait/landscape" button in print preview on Linux or Solaris. 
So the problem Chris mentioned may be a new bug, I file it as bug 151033.

Comment 15

[Paul Gregg]

for what its worth...
WFM  Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1a+) Gecko/20020703

Comment 16

[Vedran Miletic]

retargeting

Comment 17

[Wayne Mery (:wsmwk)]

WFM - dup of omnibus incredible bug 311028

*** This bug has been marked as a duplicate of 311028 ***

Comment 18

[tech]

(In reply to comment #17)
> WFM - dup of omnibus incredible bug 311028
> 
> *** This bug has been marked as a duplicate of 311028 ***
> 
impossible : this bug was reported on 2002-03-05 05:16 PST
while bug 311028 was only reported on 2005-10-04 01:44 
it's bug 311028 that should be marked as duplicate of this one ;)

Comment 19

[Wayne Mery (:wsmwk)]

(In reply to comment #18)
> (In reply to comment #17)
> > WFM - dup of omnibus incredible bug 311028
> > 
> > *** This bug has been marked as a duplicate of 311028 ***
> > 
> impossible : this bug was reported on 2002-03-05 05:16 PST
> while bug 311028 was only reported on 2005-10-04 01:44 
> it's bug 311028 that should be marked as duplicate of this one ;)

you are correct if one were to go by dates only, and it more common to dupe newer to older. however it is quite acceptable to dupe as I did if the newer bug is significantly "better", i.e. better description, better and more discussion, progress and patches.  bug 311028 is such a bug, starting at bug 311028 comment 10.  It would have made no sense for me to close 311028 and force its work and discussion into this bug.  If this bug were a regression or if dates "mattered" such that it was imperative to trace the bug's origins, then that might have affected which way to go, but neither is the case here.  The only reason to undupe would be if 311028 hadn't made progress toward fixing this bug as I anticipated it would.