User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7b) Gecko/20040405 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7b) Gecko/20040405 See below. Reproducible: Always Steps to Reproduce: 1. Make an IFRAME with a scroll bar. 2. Print Preview 3. Place the mouse over the IFRAME and scroll up and down. Actual Results: The contents of the IFRAME were scrolled. Horizontal black bars appeared and parts of the IFRAME become blurred. Expected Results: Unless there is some kind of magic paper out there which you can scroll, the print preview should always be static. And there certainly should not be any horizontal bars or blurring. Testcase and screenshot to follow. Win98se.

Zipped archive of two files, iframe.htm and iframe2.htm. View the former.

I hadn't found any open dupes of this bug when I search before, but just now I searched for any closed dupes. There was a related issue (mainly with FORM elements being scrollable in Print Preview, or PP) in bug 146395. Apparently a fix was checked in somewhere else so that scrollbars were no longer visible in PP, and this avoided the problem (the testcase for that bug works fine for me). A key difference here is that even though there is no scrollbar in PP, I can still scroll the IFRAME contents anyway! (and there is blurring).

Alright, on IRC Asa and vt100 were not able to find any dupes of this bug either.

Just to make things easier, I made a similar testcase as one file. This one uses http://www.mozilla.org as the source for the IFRAME, instead of a second file.

WFM Mozilla Linux build 2004032608 IFRAME in the print preview is static and not scrollable.

This testcase shows the same problems with the FRAME tag as I've had with IFRAME.

Three things to add about the third testcase, the one with FRAME: The print preview should be 3 pages long, but is only on 1 page. (compare scrolling with your mouse to scrolling with the scrollbar on the right). If you right click the back ground of the print preview page and select Reload, Mozilla will crash: TB15941Y Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7b) Gecko/20040409 Also, the URLs to which the hyperlinks point are displayed! But this happens now when I print preview the www.mozilla.org page by itself, without the FRAME.

Oh, it turns out that last part about the URLs being displayed was supposed to happen; its coded for in print.css. There are some other oddities with a print preview of www.mozilla.org that are not related to this bug, like how one of the images is split and how the text alignment is all off. So perhaps in testcases 2 and 3, you should switch src="http://www.mozilla.org" to some other page like src="http://www.yahoo.com".

Got the stacktrace from the new public Talkback FastFind page: Stack Signature 0x01b18adc 972b764f Product ID MozillaTrunk Build ID 2004040913 Trigger Time 2004-04-10 06:38:36.0 Platform Win32 Operating System Windows 98 4.10 build 67766446 Module null URL visited bug 239795 testcase 3 User Comments bug 239795 testcase 3. Print Preview on page containing FRAME. Right click and hit Reload. Crash. Since Last Crash null sec Total Uptime null sec Trigger Reason Access violation Source File Name Trigger Line No. Stack Trace 0x01b18adc nsSplittableFrame::Destroy [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsSplittableFrame.cpp, line 72] nsContainerFrame::Destroy [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 142] nsBoxFrame::Destroy [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBoxFrame.cpp, line 1066] nsFrameList::DestroyFrames [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/src/nsFrameList.cpp, line 130] nsContainerFrame::Destroy [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 137] ViewportFrame::Destroy [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsViewportFrame.cpp, line 68] nsFrameManager::Destroy [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsFrameManager.cpp, line 331] PresShell::Destroy [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp, line 1878] PresShell::~PresShell [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp, line 1644] PresShell::`scalar deleting destructor' PresShell::Release [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp, line 1586] nsCOMPtr_base::~nsCOMPtr_base [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpcom/glue/nsCOMPtr.cpp, line 82] nsPrintData::~nsPrintData [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/base/src/nsPrintData.cpp, line 145] 0x01dd4b50 nsVoidArray::Clear [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpcom/ds/nsVoidArray.cpp, line 593]

OK, bug 223888 covers the issue with the crash already, so we don't need to worry about that here. What I would like though is for more people to comment on whether or not they observe the scrolling and blurring I described earlier for any of the testcases.

(In reply to comment #11) > OK, bug 223888 covers the issue with the crash already, so we don't need to > worry about that here. What I would like though is for more people to comment > on whether or not they observe the scrolling and blurring I described earlier > for any of the testcases. I don't have a printer connected here so that may contribute to buggyness. On all three testcases i can scroll the frames/iframes in the "print preview". Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.7b) Gecko/20040415 Firefox/0.8.0+

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

Lots of discussion on this bug in Chatzilla. A few people were able to confirm this bug. We certainly would want to try to fix this for 1.7final. Just to clarify things, when I wrote "scroll up and down" in my original bug report, I meant scrolling with your mouse wheel. A print preview of my testcases crashed Mozilla for BZ, so he filed a separate bug as 241163. (I believe this has to do with using www.mozilla.org as the FRAME/IFRAME source and not so much this bug). Christopher wrote: "fwiw 239795 (and 241163) are WFM in ff 0.8, but I guess you already knew it is a recent regression" bz recommended I CC roc and bryner, as I have done. bz wrote: "can believe mousewheel screwing up the print preview event blocking...." There was a similar but distinct issue listed in bug 129941, except that was with tables.

I've gone through a bunch of past nightly trunk builds, and it turns out the issue with scrolling frame/iframe contents in print preview is indeed a regression between 2004-01-09 and 2004-01-10. A quick look through Bonsai indicates it may be due to roc's work in Bug 225820. Also, it turns out the issue with the print preview of a multipage frame only showing up as one page existed before that date, so it is likely a separate issue. Perhaps I should open up a separate bug for that.

Bug 247166 and bug 247170 are also about problems with printing and previewing pages with frames. According to bug 129941 comment 32 these bugs could be duplicates of this bug.

(In reply to comment #16) > Bug 247166 and bug 247170 are also about problems with printing and previewing > pages with frames. Since there are two different problems involved here, let's let this bug be only for the scrolling in print preview issue and use bug 247166 for the only-get-one-page-when-printing issue.

Using a Trunk 2004-10-22 build, it is no longer possible to scroll the contents of a FRAME or IFRAME with the mouse wheel. This must have been fixed somewhere else. Note that the bug where only one page of a FRAME is printed or print previewed was already listed as bug 178554.