Page setup and Print preview fails

VERIFIED FIXED

Status

()

Core
Print Preview
--
major
VERIFIED FIXED
13 years ago
12 years ago

People

(Reporter: Hari Kumar G, Assigned: vlad)

Tracking

({regression, verified1.8})

Trunk
x86
All
regression, verified1.8
Points:
---
Bug Flags:
blocking1.8b5 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050727 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050727 Firefox/1.0+

The print priview zoom values as well as page setup zoom / orientation is not
working in nightly builds of Ffx 1.5

Reproducible: Always

Steps to Reproduce:
1.Open a web page in a recent build of Ffx 1.0 +,
2.Choose print preview from the file menu.  CLick the page setup from the menu
3.Adjust the zoom value/ portrait-landscape etc. Click Ok.

Actual Results:  
Nothing

Expected Results:  
Zoom should be adjusted to the value opted from the dialog.  So the orientation
of the page.

Is it broken in the nightly builds or temporarily disabled due to the
modifications in nightlies?

Comment 1

13 years ago
The prefs seem to be broken in general. See
https://bugzilla.mozilla.org/show_bug.cgi?id=267422#c26

Comment 2

13 years ago
Confirmed!

Attempting to use "Shrink to Fit" and or switching between "Portrait" and
"Landscape" the JCON Reports: Error: uncaught exception: [Exception...
"Component returned failure code: 0x80004005 (NS_ERROR_FAILURE)
[nsIPrintSettingsService.savePrintSettingsToPrefs]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame ::
chrome://global/content/printUtils.js :: anonymous :: line 86"  data: no]

BUILD: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050802
Firefox/1.0+ ID:2005080209

Flags: blocking-aviary1.5?

Updated

13 years ago
Assignee: nobody → printing
Severity: normal → major
Status: UNCONFIRMED → NEW
Component: General → Print Preview
Ever confirmed: true
Flags: blocking1.8b4?
OS: Windows 2000 → All
Product: Firefox → Core
QA Contact: general
Version: unspecified → Trunk

Updated

13 years ago
Keywords: regression, useless-UI

Comment 3

13 years ago
no need for two blocking? flags
Flags: blocking-aviary1.5?

Comment 4

13 years ago
Josh,

Can you take a first pass to help us narrow down either a fix or a better owner
for this?

Assignee: printing → joshmoz
Flags: blocking1.8b4? → blocking-aviary1.5+
(Reporter)

Comment 5

13 years ago
As far I remember this bug was there as early as builds from July 20, 2005.

Comment 6

13 years ago
I spent a few hours looking at archived builds and checkins in attempt to
determine when things happened. Print preview on the trunk has regressed over
several months.  

There is some print preview display ugliness, bug 267422, which is blocked by
this bug.  That bug has been around since at least 2004-11-02.

The preview controls broke at two different times:
In the Main Print Preview window, The scale tool and orientation buttons broke
between builds 2004-12-19-08-trunk (works) and 2004-12-20-08-trunk (broken). 
That bustage was reported immediately in bug 275387.  However, it wasn't
confirmed until I did the first BFT run against the trunk on 2005-05-18.  

At that time, I discovered that the Scale function in Page Setup was stuck on
shrink-to-fit. It also regressed on the 2004-12-20 build.  Although sometime
between Dec '04 and the build on 2005-05-18 that was fixed.

But then both Orientation and Scale in Print Preview | Page Setup broke between
builds 2005-07-19-06-trunk (works) and 2005-07-20-07-trunk (broken as Hari stated)

A checkin involving print for bug 270079 landed in the regression window for the
main page controls.
Then a checkin involving print for bug 297277 landed during the regression
window for the Page Setup controls.
Both of those fixes were in nsPrintOptionsImpl.cpp
http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/gfx/src/nsPrintOptionsImpl.cpp
Blocks: 267422

Comment 7

13 years ago
*** Bug 275387 has been marked as a duplicate of this bug. ***

Comment 8

13 years ago
(In reply to comment #0)
>... 
> The print priview zoom values as well as page setup zoom / orientation is not
> working in nightly builds of Ffx 1.5

More precisely, it does not redraw the screen with new setting after using menu
options or buttons or changing via "page setup".

However, if you exit print preview after using "page setup" then print preview
displays with those options.

Happens for me with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4)
Gecko/20050808 Firefox/1.0+ on XP home.

but I don't get precisely the same behavior with Mozilla/5.0 (Windows; U;
Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050816 Firefox/1.0+ on XP-PRO. There I
get bug 267422.
This is just my guess of bug 267422:

We, in printPreviewBindings.xml and printUtils.js, assume a settings
(I mean, an object which has nsIPrintSettings interface) from
nsIPrintSettingsService::globalSettings modified with 
...::initPrintSettingsFromPrinter and ...::initPrintSettingsFromPrefs
should be same as the settings nsIWebBrowserPrint::currentPrintSettings
returns. (Ummmm, confusing...)

However, as mentioned comment #6, the fix for bug 270079 changed the behavior
of ...::globalSettings, then it always returns the initial settings
instead of the current settings.

We are calling globalSettings everytime the user resize the print preview,
but probably that's a evil implementation.

According to 270079c#2,
> Change this will not change the performance, since this function
> will only be invoked two times, when browser start printing/preview
> and when mailnews start priting/preview.
Created attachment 194007 [details] [diff] [review]
Patch

UIs will be back.

Anyone knows there's a similar bug on seamonkey as well?
Attachment #194007 - Flags: review?(joshmoz)

Comment 11

13 years ago
WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050831
Firefox/1.0+

Torisugari, does your patch fix this bug or a different bug?

Comment 12

13 years ago
WFM Firefox 1.5 brnach build from today (see time of this post).

torisugari: what does your patch fix?
Uhm, I believed I was talking about this bug, but now I'm not too sure.
I can still reproduce this(?) bug with today's branch/trunk + a new profile.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4)
Gecko/20050901 Firefox/1.0+

Steps to reproduce:
1. "File" -> "Print Preview"
2. Push "Landscape" button.

Actual result:
That functionality works, but the landscape button is not "in".

Expected result:
If a user push these buttons, they should look pushed.


Print preveiw toolbar's "orient()" method tries to change the buttons status,
but "updateToolbar()" method switch back that status.

Anyway, the script sets

this.mLandscapeButton.checked = true/false;

too many times.

Comment 14

13 years ago
not failing for us on 1.5. unsetting request.
Flags: blocking-aviary1.5+
torisugari,  Are you certain the functionality of the main preview orientation
buttons are working?  It's still broken for me. Please see bug 275387. Also bug
267422 can make it difficult to tell without resizing the window.

Comment 16

13 years ago
Has the patch been checked in somewhere ?

(In reply to comment #14)
> not failing for us on 1.5. unsetting request.

OK, it DOES work, if you change settings in the Print Setup Dialog.
(Did you notice the funny change of the bottom line, if you toggle between
Portrait and Landscape, BTW) - And the redraw isn't right (bug 267422 ?).

But the direct settings (Scale, and the Portrait/Landscape Buttons) don't work
at all. Seing that Bug 275387 is reopened (used to be a dupe of this one),
shouldn't that one be set to block instead? 
(I'll request that... I use Print Preview a lot, and it not properly working
would block me from upgrading 1.0.6   :-(  )
(Reporter)

Comment 17

13 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050906 Firefox/1.4

isn't that a regression serious enough to be resolved before firefox 1.5?

Updated

13 years ago
Flags: blocking-aviary2.0?

Comment 18

13 years ago
(In reply to comment #17)
> Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050906
Firefox/1.4
> 
> isn't that a regression serious enough to be resolved before firefox 1.5?

i agree this should be fixed before it is released
Flags: blocking1.8b5?

Comment 19

13 years ago
we're blocking on the two bugs mentioned in comment #16. I think that's
sufficient. if you disagree, please renominate with an explanation of what's
still failing here that's not covered in those bugs. Thanks.
Flags: blocking1.8b5? → blocking1.8b5-

Updated

13 years ago
Assignee: joshmoz → mscott
Comment on attachment 194007 [details] [diff] [review]
Patch

I've got a better fix for this coming
Attachment #194007 - Flags: review?(joshmoz) → review-
Assignee: mscott → vladimir
fixed with check-in for bug 267422.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Flags: blocking-aviary2.0?
Resolution: --- → FIXED

Updated

12 years ago
Keywords: useless-UI → fixed1.8

Updated

12 years ago
Status: RESOLVED → VERIFIED
Keywords: fixed1.8 → verified1.8
You need to log in before you can comment on or make changes to this bug.