Closed Bug 239795 Opened 20 years ago Closed 20 years ago

in print preview, contents of FRAME or IFRAME can be scrolled and then blur

Categories

(Core :: Print Preview, defect, P2)

x86
Windows 98
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mozilla, Assigned: roc)

References

Details

(Keywords: regression)

Attachments

(4 files)

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.
Attached file testcase1
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.
Severity: normal → major
Summary: in print preview, contents of IFRAME can be scrolled and then blur → in print preview, contents of FRAME or IFRAME can be scrolled and then blur
   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+
Depends on: 241163
*** 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.
Keywords: regression
Assignee: core.printing → roc
Priority: -- → P2
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.

Severity: major → normal
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.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: