Closed Bug 311028 Opened 19 years ago Closed 19 years ago

Print Preview window is partly overlayed by background and is missing scrollbars

Categories

(Core :: Print Preview, defect)

x86
All
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla1.8.1

People

(Reporter: aha, Assigned: iannbugzilla)

References

Details

(Keywords: fixed-seamonkey1.1a, fixed1.8.1, regression)

Attachments

(1 file, 5 obsolete files)

2004110104/trunk/W2K

Repro:
1. open http://www.pcmag.com/article2/0,1759,1937,00.asp
2. open Print Preview window
3. in Page Setup switch Print Backgrounds

Actual:
Part of Print Preview window is overlayed by XUL default background.

Bug was fixed by Vlad for toolkit, different fix is probably needed for SeaMonkey.
Flags: blocking-seamonkey1.0b?
Keywords: regression
No longer depends on: 267422
Remains broken in OS/2 trunk 2005100407 -> ALL
OS: Windows XP → All
I see this as well in 1.5b1 on Windows (Mozilla/5.0 (Windows; U; Windows NT 5.0;
en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4)

Screenshots:
http://img114.imageshack.us/img114/1563/image13va.png (before Print Backgrounds)
http://img114.imageshack.us/img114/3123/image24ti.png (after Print Backgrounds)
Ian, want to take a stab at this?
Blocks: 125824
Confirming with SeaMonkey 1.0a (20050910) on Win 98SE.  This bug *also* occurs
after a scale change is made.  Example: choose another scale percentage from the
drop-down list other than "Shrink to Fit," and bug is seen once new scale
setting has been applied to the preview window.
Hmm, can someone look into that? It's not visible with default settings, as IIRC backgrounds are off there. Because of this and noone working on it, I'm tempted to mark this one blocking-, so that we'll be able to ship a Beta...
Kairo, try to switch just between Portrait and Landscape mode, bug is also present. Probably any operation in Print Preview, which leads to new re-layout, will cause this bug.
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051112 SeaMonkey/1.5a 

testing https://bugzilla.mozilla.org/page.cgi?id=fields.html#status
P=Portrait, L=Landscape, H=Horizontal,  V=Vertical Scrollbar

Starting in P-Mode: P: HV -> L: HV -> P:    -> L:  V -> P:    > L:  V ->....
Starting in L-Mode:          L: HV -> P: H  -> L:  V -> P:    > L:  V ->....

Vertical scrollbar: cursorkeys also working
Bug starts with 1st change from L to P, vertical scrollbar gets replaced with XUL background of twice the scrollbar width.
After this switching from P to L re-adds the scrollbar, replacing part of the images, not the background, so now to the right there is one scrollbar width scrollbar, and two widths background.

Horizontal scrollbar: cursorkeys not working
H Scrollbar is hidden on 2nd change:
Open Preview in any mode, H seen, change mode, H seen, change mode, H gone


Also seen on the testpage, but that's another bug: 1st table doesn't fit on page 1, rest lost, 2nd page starts with markup following the 1st table, i.e.  <h2> Severity, and the 2nd table. I'm seeing this in screen resolution 800x600, don't have a printer.
does comment 8 implicate bug 130048? (is 130048 even still valid? I don't know enough to judge)

dup bug 291497 to this one?  
Or dup both to ... (take your pick, there are others re: scrollbars)?

nice work Herman - this largely confirms testing I was about to write up :) - curious behavior
Component: General → Print Preview
Flags: blocking-seamonkey1.0b?
Product: Mozilla Application Suite → Core
Assignee: general → printing
QA Contact: general
Attached patch Port printutils patch v0.1a (obsolete) — Splinter Review
This patch:
* Port toolkit's print preview system including patch on bug 267422
* Fix mailnews so it can use new print preview system
* Fixes issues with unnecessary redraws eg clicking on Portrait twice
* Fixes issues with page numbers not being reset when scaling / changing orientation
* Fixes issues with page total not being recalculated when scaling / changing orientation
* Backport above issues to toolkit's printpreview system

Other stuff to possibly do:
* Switch NSPrint() calls to PrintUtils.print() calls
* Switch NSPrintSetup() calls to PrintUtils.showPageSetup() calls
Assignee: printing → iann_bugzilla
Status: NEW → ASSIGNED
Attachment #203322 - Flags: review?(neil.parkwaycc.co.uk)
*** Bug 291497 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary2?
'worcester12345'--this has nothing to do with Aviary, as they use tookit.  See like, comment 0.
Flags: blocking-aviary2?
(In reply to comment #12)
> 'worcester12345'--this has nothing to do with Aviary, as they use tookit.  See
> like, comment 0.
> 

Sorry. My bad. I bounce back and forth from Firefox to Mozilla Suite often. 
(In reply to comment #10)
> * Fix mailnews so it can use new print preview system

Is it possible to fix bug 66806 as well?
This bug was perhaps first reported on 2005-04-22 12:14 PST (#291497). Clicking a full-size window to "restore" size or vice versa fixes the display problem, I think.
This problem with print preview seems to be fixed in Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.12) Gecko/20051208. It displays properly after scale changes.

(In reply to comment #16)
> This problem with print preview seems to be fixed in Mozilla/5.0 (Windows; U;
> Win98; en-US; rv:1.7.12) Gecko/20051208. It displays properly after scale
> changes.

John, this is a regression from 1.8 on that lives in the trunk.  The build you referenced is a branch build, hence why you can't see this bug.
Attachment #203322 - Flags: review?(neil.parkwaycc.co.uk)
Changes since v0.1a:
* Spun off toolkit changes to bug 321153
Attachment #203322 - Attachment is obsolete: true
Attachment #206552 - Flags: review?(neil.parkwaycc.co.uk)
Comment on attachment 206552 [details] [diff] [review]
Revised port of printutils patch v0.1b

Well, I guess most of this is moving stuff around so you don't want to fix the nits I mentioned on IRC. I see Print Preview isn't very accessible either, but hiding and showing the toolbar isn't going to help, I'd prefer if you collapse it instead, or better still, collapse the browser, as that looks visually superior to me.
Attachment #206552 - Flags: review?(neil.parkwaycc.co.uk) → review+
(In reply to comment #18)
> Created an attachment (id=206552) [edit]
> Revised port of printutils patch v0.1b
> 
> Changes since v0.1a:
> * Spun off toolkit changes to bug 321153
> 

Should this then be dependent on 321153?
Attached patch Collapsed browser patch v0.1c (obsolete) — Splinter Review
Changes since v0.1b:
* Fixed typo Prgress -> Progress
* Added missing IID for nsISupports in QueryInterface function
* Collapse browser instead of hiding toolbar
Attachment #206552 - Attachment is obsolete: true
Attachment #207039 - Flags: review?(neil.parkwaycc.co.uk)
Comment on attachment 207039 [details] [diff] [review]
Collapsed browser patch v0.1c

r=me if you remove the _debug bits :-P
Attachment #207039 - Flags: review?(neil.parkwaycc.co.uk) → review+
Comment on attachment 207039 [details] [diff] [review]
Collapsed browser patch v0.1c

leaving _debug as is as was put back in after removing in a previous patch - discussed with Neil on IRC
Attachment #207039 - Flags: superreview?(bienvenu)
Comment on attachment 207039 [details] [diff] [review]
Collapsed browser patch v0.1c

why the all upper-case var names? e.g.? Is this a new fad I'm not up on? :-)

+      var PRINTPROMPTSVC = Components.classes["@mozilla.org/embedcomp/printingprompt-service;1"]
+                                     .getService(Components.interfaces.nsIPrintingPromptService);
+      PRINTPROMPTSVC.showPageSetup(window, printSettings, null);

the diffs look like they've got two copies of themselves - I only looked at the first half/copy :-)

Thunderbird seems to use the mailnews version of the affected files (or at least, msgPrintEngine.js but not msgPrintEngine.xul - do you need me to try this patch with thunderbird, or have you tried TB? Does TB need the same changes to its copy of msgPrintEngine.xul)

I'll mark this sr, but please let me know about TB before you checkin.

Thx for doing this!
Attachment #207039 - Flags: superreview?(bienvenu) → superreview+
Attached patch Non duplicated patch v0.1c (obsolete) — Splinter Review
Correct version without duplicating diff, carrying over r/sr=
Attachment #207039 - Attachment is obsolete: true
Attachment #207225 - Flags: superreview+
Attachment #207225 - Flags: review+
Changes from v0.1c:
* Removed all caps variable names
* Fixed printing.js and editor.js so printing works in composer
* Fixed mail's msgPrintEngine.xul so it works with printing.js

I've created bug 321954 to make printUtils.js easier to hook into (maybe porting some of the changes here to toolkit)
Attachment #207225 - Attachment is obsolete: true
Attachment #207227 - Flags: superreview?(bienvenu)
Attachment #207227 - Flags: review?(neil.parkwaycc.co.uk)
Attachment #207227 - Flags: superreview?(bienvenu)
Attachment #207227 - Flags: review?(neil.parkwaycc.co.uk)
Changes since v0.1d:
* Put gInPrintPreviewMode setting back into browser.js it works in navigator.js
* Removed unused variables gOldCloseHandler and gWebProgress from browser.js
Attachment #207227 - Attachment is obsolete: true
Attachment #207272 - Flags: superreview?(bienvenu)
Attachment #207272 - Flags: review?(neil.parkwaycc.co.uk)
Attachment #207272 - Flags: review?(neil.parkwaycc.co.uk) → review+
Comment on attachment 207272 [details] [diff] [review]
gInPrintPreviewMode patch v0.1e (Checked into trunk and branch 1.8)

thx very much for taking this on.
Attachment #207272 - Flags: superreview?(bienvenu) → superreview+
Comment on attachment 207272 [details] [diff] [review]
gInPrintPreviewMode patch v0.1e (Checked into trunk and branch 1.8)

Checking in (trunk)
mailnews/base/resources/content/msgPrintEngine.js;
new revision: 1.22; previous revision: 1.21
mailnews/base/resources/content/msgPrintEngine.xul;
new revision: 1.18; previous revision: 1.17
xpfe/browser/resources/content/browser.js;
new revision: 1.35; previous revision: 1.34
xpfe/communicator/resources/content/printing.js;
new revision: 1.9; previous revision: 1.8
xpfe/communicator/resources/content/printPreviewBindings.xml;
new revision: 1.24; previous revision: 1.23
xpfe/communicator/resources/locale/en-US/printPreview.dtd;
new revision: 1.6; previous revision: 1.5
editor/ui/composer/content/editor.js;
new revision: 1.236; previous revision: 1.235
mail/base/content/msgPrintEngine.xul;
new revision: 1.6; previous revision: 1.5
done
Attachment #207272 - Attachment description: gInPrintPreviewMode patch v0.1e → gInPrintPreviewMode patch v0.1e (Checked into trunk)
Comment on attachment 207272 [details] [diff] [review]
gInPrintPreviewMode patch v0.1e (Checked into trunk and branch 1.8)

Requesting approval for landing on 1.8.1 branch, asking for the mail part of the patch (will request SM approval via IRC), would be good to fix this regression.
Attachment #207272 - Flags: approval1.8.1?
Comment on attachment 207272 [details] [diff] [review]
gInPrintPreviewMode patch v0.1e (Checked into trunk and branch 1.8)

Would also really like to get this into 1.8.0 branch too.
Attachment #207272 - Flags: approval1.8.0.1?
Ian-can you mark this FIXED now that it's landed on the trunk?  I'm all set to verify it (looks good), but I don't want to jump states.
-> Fixed as it is on trunk
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Verified FIXED on trunk using SeaMonkey 1.5a;Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060105 Mozilla/1.0

Notes:
* Orientation (Portrait/Landscape) now retains its last state (nice)
* The Portrait and Landscape buttons no longer erroneously accept a click when they're already depressed.
Status: RESOLVED → VERIFIED
Comment on attachment 207272 [details] [diff] [review]
gInPrintPreviewMode patch v0.1e (Checked into trunk and branch 1.8)

a-=schrep 1.8.0 and a+=schrep for 1.8.1 for drivers.   Given the size of the patch would prefer to land for 1.8.1/FF2 timeframe.
Attachment #207272 - Flags: approval1.8.1?
Attachment #207272 - Flags: approval1.8.1+
Attachment #207272 - Flags: approval1.8.0.1?
Attachment #207272 - Flags: approval1.8.0.1-
Comment on attachment 207272 [details] [diff] [review]
gInPrintPreviewMode patch v0.1e (Checked into trunk and branch 1.8)

approval-seamonkey1.1=me
Comment on attachment 207272 [details] [diff] [review]
gInPrintPreviewMode patch v0.1e (Checked into trunk and branch 1.8)

Checking in (branch 1.8)
mailnews/base/resources/content/msgPrintEngine.js;
new revision: 1.21.4.1; previous revision: 1.21
mailnews/base/resources/content/msgPrintEngine.xul;
new revision: 1.17.8.1; previous revision: 1.17
xpfe/browser/resources/content/browser.js;
new revision: 1.34.12.1; previous revision: 1.34
xpfe/communicator/resources/content/printing.js;
new revision: 1.7.4.2; previous revision: 1.7.4.1
xpfe/communicator/resources/content/printPreviewBindings.xml;
new revision: 1.23.2.1; previous revision: 1.23
xpfe/communicator/resources/locale/en-US/printPreview.dtd;
new revision: 1.5.58.1; previous revision: 1.5
editor/ui/composer/content/editor.js;
new revision: 1.235.2.1; previous revision: 1.235
mail/base/content/msgPrintEngine.xul;
new revision: 1.5.4.1; previous revision: 1.5
done
Attachment #207272 - Attachment description: gInPrintPreviewMode patch v0.1e (Checked into trunk) → gInPrintPreviewMode patch v0.1e (Checked into trunk and branch 1.8)
Keywords: fixed1.8.1
Whiteboard: fixed-seamonkey1.1
What parts of this are in shared code and what parts are SeaMonkey-only?
If I understand correctly, mtschrep complains about the patch size for 1.8.0 branch, though most of the patch is in code that doesn't need driver approval anyways, only SeaMonkey approval.
From the SeaMonkey side, I could live with approval for 1.0 probably, but someone needs to approve the non-SeaMonkey-specific parts on behalf of drivers. Maybe if we could split off that part, mtschrep might feel better (and it would be nice to get him to agree, as he was the one marking the minus)...
Target Milestone: --- → mozilla1.8.1
Whiteboard: fixed-seamonkey1.1
*** Bug 325010 has been marked as a duplicate of this bug. ***
(In reply to comment #38)
> What parts of this are in shared code and what parts are SeaMonkey-only?
> If I understand correctly, mtschrep complains about the patch size for 1.8.0
> branch, though most of the patch is in code that doesn't need driver approval
> anyways, only SeaMonkey approval.
> From the SeaMonkey side, I could live with approval for 1.0 probably, but
> someone needs to approve the non-SeaMonkey-specific parts on behalf of drivers.
> Maybe if we could split off that part, mtschrep might feel better (and it would
> be nice to get him to agree, as he was the one marking the minus)...
> 

Has anybody followed up on this?
Blocks: 324141
(In reply to comment #40)
> (In reply to comment #38)
> > What parts of this are in shared code and what parts are SeaMonkey-only?
> > If I understand correctly, mtschrep complains about the patch size for 1.8.0
> > branch, though most of the patch is in code that doesn't need driver approval
> > anyways, only SeaMonkey approval.
> > From the SeaMonkey side, I could live with approval for 1.0 probably, but
> > someone needs to approve the non-SeaMonkey-specific parts on behalf of drivers.
> > Maybe if we could split off that part, mtschrep might feel better (and it would
> > be nice to get him to agree, as he was the one marking the minus)...
> > 
> 
> Has anybody followed up on this?
> 
Sorry this was discussed on IRC but I never followed up by posting a response here.
It is nearly all shared code as TB uses parts of the toolkit and xpfe printing systems. I did look at trying to create an SM only patch but would have meant forking msgPrintEngine.js for TB which again would have probably been too much code change for 1.8.0.
*** Bug 324772 has been marked as a duplicate of this bug. ***
The print preview is broken again (cut). Try scaling of any page or just scroll down multiple pages (e.g. "LICENCE" file in seamonkey directory). 

Although 
"Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060124 SeaMonkey/1.5a"
and some builds before seemed to be ok, todays build 
"Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060130 SeaMonkey/1.5a" has problems again.
Tried also with build from 20060127 which was broken, too.
Using Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.12) Gecko/20060129, I found that the scroll bars seem to be OK at all the settings I tried, but the sizing of text has a problem. Displaying this bugzilla page at 50%, it's 5 pages long, but at 40% it's 9 pages long and the text below this text entry box isn't shrunk to 40%. It's quite a bit larger (100%?), making the total length 9 pages. The text in this box is the larger size too.
Markus, please log a new bug and cc me in (or least mention the bug number here).
Include steps on how to reproduce, describe what is different and, if possible, attach to that bug a screenshot so I can compare to what I see here.
(In reply to comment #45)
> Markus, please log a new bug and cc me in (or least mention the bug number
> here).
> Include steps on how to reproduce, describe what is different and, if possible,
> attach to that bug a screenshot so I can compare to what I see here.
> 
Okay, I think I have the same thing so logged bug 325276
(In reply to comment #42)
> *** Bug 324772 has been marked as a duplicate of this bug. ***
> 
Hello, 
even if there's mention of the zoom problem in some comments here, and the two bugs seems linked, the main description "Print Preview window is partly overlayed by background and is missing scrollbars" doesn't match at all the fact that When changing the size in print preview, nothing happens. 
Why not titling "there are problems with print preview" ?
I think you might receive many duplicates... 
Blocks: 326480
*** Bug 129033 has been marked as a duplicate of this bug. ***
Blocks: 231894
*** Bug 355911 has been marked as a duplicate of this bug. ***
Depends on: 351913
As it seems that any kind of printing preview problem are told to be duplicates of this one, even if the title (Print Preview window is partly overlayed by background and is missing scrollbars) as nothing to do with the actuel problem, I add here other examples of page which are not correctly shown.
I'll add the same infos in the bug #324772 I've already reported...

It's still impossible to change the printing preview size of the page I mentioned 
http://www.mozilla.org/support/firefox/faq 

either with SeaMonkey/1.1.1 or with Firefox/2.0.0.3 (under windows XP SP1)
but with Seamonkey the change between landscape and portrait works, not with Firefox.
I also tried with Seamonkey under Linux Mandriva 2006, and in this case the buttons for size and orientation show briefly when the window open then totally disappear, so I can't test if they work !

I recently tried to print this page at a reduced size, to save some paper :
http://www.w3.org/QA/2005/04/php-session
but it's another time impossible to change printing and preview size, either with Seamonkey or Firefox. Strangely, with this page, the orientation change works with both !

I wanted to insist that event if I had many strange behaviour in the printing preview window, I HAVE ABSOLUTELY NEVER seen "the window partly overlayed by background and is missing scrollbars". So I still think the bugs are not the same, and it's certainly why the one I describe isn't fixed yet.
No longer blocks: 125824
You need to log in before you can comment on or make changes to this bug.