127891 - [TRUNK ONLY][BRANCH NOT AFFECTED BY THIS BUG] still broken] cannot properly print or print preview IFrames or FrameSets

Status: VERIFIED FIXED

(Core :: Printing: Output, defect)

Description

[Tracy Walker [:tracy]]

seen on mac os9 commercial build 2002-02-26-03-trunk
also saw this on yesterdays build.

-open home.netscape.com
-Click on print and run through dialog to rpint the page
the page isn't printed...however other pages seem to print fine

Comment 1

[rods (gone)]

don, I need you take a look.

Comment 2

[dcone (gone)]

My pull from a few days ago..prints fine.  I will do a pull from today.. see if 
I get the same behavior.

Comment 3

[sujay]

I also saw this problem using 2/25 trunk build on Mac...I could not
print the NSCP home page at all...

Comment 4

[Tracy Walker [:tracy]]

this worked today on windows mac os9 commercial build 2002-02-27-03-trunk

Comment 5

[sujay]

I still cannot print the NSCP home page using today's 2/27 trunk build on Mac.

Comment 6

[sujay]

hmm...now it worksforme....

Comment 7

[sujay]

marking it WFM...tracy keep an eye out for this in smoketesting...

Comment 8

[sujay]

verified.

Comment 9

[Tracy Walker [:tracy]]

this is back on mac os9 commercial build 2002-03-01-03-trunk

can't print home.netscape.com

Comment 10

[sujay]

me also...I saw this problem yesterday....Tracy, good job at monitoring this..
I'll also monitor it...lets keep this bug open...

Comment 11

[sujay]

not only does it not print, I do crash also sometimes. using 3/1 mac trunk
on 9.x machine.

Talkback coming...

Comment 12

[Tracy Walker [:tracy]]

i was able to print home.netscape.com with os9 today. commercial build 
2002-03-08-03-trunk

Comment 13

[sujay]

now I get a crash

Incident ID 3808085
 Stack Signature
                  0xffc10008 6fa81428
 Trigger Time
                  2002-03-08 11:39:46
 Email Address
                  [e-mail]
 URL visited
 Build ID
                  2002030803
 Product ID
                  MozillaTrunk
 Platform
 Operating System
                  MacOS
 Module
 Trigger Reason
                   Illegal PowerPC instruction
 User Comments
                  crashed in mac 
 Stack Trace

0xffc10008 
view.shlb + 0x6f64 (0x3cba1894) 
view.shlb + 0x19a8 (0x3cb9c2d8) 
view.shlb + 0x118ec (0x3cbac21c) 
layout.shlb + 0xe1e4c (0x3cc9ecfc) 
layout.shlb + 0xe2228 (0x3cc9f0d8) 
layout.shlb + 0x1e60 (0x3cbbed10) 
layout.shlb + 0xd6b2c (0x3cc939dc) 
layout.shlb + 0xd7a84 (0x3cc94934) 
layout.shlb + 0xaeaf0 (0x3cc6b9a0) 

Comment 14

[Tracy Walker [:tracy]]

yep, I crashed today when I made a second attempt to print the page.  It didn't 
print the first time.

Comment 15

[sujay]

Tracy, is this still a problem?

Comment 16

[Tracy Walker [:tracy]]

yes, still a problem.  currently on os9 the print status dialog doesn't close, 
the page isn't printed. The dialog won't go away unless the app is restarted, 
But it doesn't seem to affect continuing with smoketesting. I have been 
restarting the app just to be certain.

Comment 17

[Tracy Walker [:tracy]]

the same behavior is happening on osx too.

printing various other pages works on os9 and osx.

Comment 18

[Chris Petersen]

This might be related to print a frameset or iframe element (home.netscape uses
a iframe element). If you attempt print either test, you will get similar
results: Print dialog doesn't close and page is not printed out. Tested under OS
X March 25 th build.


http://mozilla.org/quality/browser/standards/html/iframe_align_bottom.html

http://mozilla.org/quality/browser/standards/html/frame_scrolling_yes_cols.html

Comment 19

[sujay]

Tracy, still a problem ?

Comment 20

[Tracy Walker [:tracy]]

still a problem on macs and now seeing windows failing to print 
home.netscape.com also.  windows pops up an erro say "Printing failed when 
completing the document"

Comment 21

[Tracy Walker [:tracy]]

still a problem and verified with windows commercial trunk build 
2002-04-16-06-trunk that I get the fails print pop up.

printing the smoketest page works (it's not the printer)

Comment 22

[Zach Lipton [:zach]]

Seeing this on the 1.0 RC test build on mac os x 2002041712, printing google.com
works ok though. 

Comment 23

[Tracy Walker [:tracy]]

now crashing in attempt to print home.netscape.com on mac and windows.  This 
should be a smoketest blocker. It fails the smoketest and there isn't a work 
around.  This has been around for nearly two months.  If this bug isn't 
considered a smoketest blocker then the test should be removed from the 
smoketests or changed to a site that is printable..

here is the talkback data for the windows crash:

Incident ID 5342611
 Stack Signature
                  DocumentViewerImpl::ReflowPrintObject a2ed2803
 Trigger Time
                 2002-04-18 08:19:51
 Email Address
                 [e-mail]
 URL visited
 Build ID
                 2002041806
 Product ID
                 MozillaTrunk
 Platform
 Operating System
                 Win32
 Module
 Trigger Reason
                 Access violation
 User Comments
                 crash printing home.netscape.com 
 Stack Trace

DocumentViewerImpl::ReflowPrintObject 
[d:\builds\seamonkey\mozilla\content\base\src\nsDocumentViewer.cpp, line 3636] 
DocumentViewerImpl::ReflowDocList 
[d:\builds\seamonkey\mozilla\content\base\src\nsDocumentViewer.cpp, line 3594] 
DocumentViewerImpl::ReflowDocList 
[d:\builds\seamonkey\mozilla\content\base\src\nsDocumentViewer.cpp, line 3608] 
DocumentViewerImpl::SetupToPrintContent 
[d:\builds\seamonkey\mozilla\content\base\src\nsDocumentViewer.cpp, line 4417] 
DocumentViewerImpl::DocumentReadyForPrinting 
[d:\builds\seamonkey\mozilla\content\base\src\nsDocumentViewer.cpp, line 5182] 
DocumentViewerImpl::Print 
[d:\builds\seamonkey\mozilla\content\base\src\nsDocumentViewer.cpp, line 6994] 
XPTC_InvokeByIndex 
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp, 
line 106] 
XPCWrappedNative::CallMethod 
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp, line 
2027] 
XPC_WN_CallMethod 
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp, 
line 1267] 
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 790] 
js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2746] 
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 806] 
js_InternalInvoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 881] 
JS_CallFunctionValue [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 3414] 
nsJSContext::CallEventHandler 
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 1019] 
nsJSEventListener::HandleEvent 
[d:\builds\seamonkey\mozilla\dom\src\events\nsJSEventListener.cpp, line 184] 
nsEventListenerManager::HandleEventSubType 
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line 
1220] 
nsEventListenerManager::HandleEvent 
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line 
2212] 
nsXULElement::HandleDOMEvent 
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 
3461] 
nsXULElement::HandleDOMEvent 
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 
3480] 
nsXULElement::HandleDOMEvent 
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 
3480] 
PresShell::HandleDOMEventWithTarget 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6037] 
nsButtonBoxFrame::MouseClicked 
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsButtonBoxFrame.cpp, line 195] 
nsButtonBoxFrame::HandleEvent 
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsButtonBoxFrame.cpp, line 142] 
PresShell::HandleEventInternal 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6006] 
PresShell::HandleEventWithTarget 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5957] 
nsEventStateManager::CheckForAndDispatchClick 
[d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 
2624] 
nsEventStateManager::PostHandleEvent 
[d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 
1705] 
PresShell::HandleEventInternal 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6010] 
PresShell::HandleEvent 
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5912] 
nsViewManager::HandleEvent 
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 2076] 
nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 306] 
nsViewManager::DispatchEvent 
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1887] 
HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 83] 
nsWindow::DispatchEvent 
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 869] 
nsWindow::DispatchWindowEvent 
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 886] 
nsWindow::DispatchMouseEvent 
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4713] 
ChildWindow::DispatchMouseEvent 
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4968] 
nsWindow::ProcessMessage 
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3630] 
nsWindow::WindowProc 
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 1131] 
KERNEL32.DLL + 0x363b (0xbff7363b) 
KERNEL32.DLL + 0x24407 (0xbff94407) 
0x00688bfa 

Comment 24

[Roland Mainz]

tracy:
Does it help when you turn-off "Shrink to fit" in the page setup ?

Comment 25

[Tracy Walker [:tracy]]

there isn't a "shrink to fit.. " selection on mac.

but on windows I turned off the shrink to fit. Printing didn't crash, but it got 
the printing failed pop up.  then I went back and turned on shrink to fit, tried 
printing and it worked. 

Comment 26

[Roland Mainz]

Weired.

Can someone run a build under Rational Purify-control on Windows and check if
there any UMRs or other issues, please ?

Comment 27

[sujay]

OK I just installed the 4/18 trunk build:

1) with STF on by default I crash when printing the home.netscape.com page
2) with STF off, I do not crash when printing the home.netscape.com page

with 4/17 branch build the home page prints regardless of whether STF is
on or off.

Comment 28

[rods (gone)]

jst, your IFrame check in has broken the printing of IFrames when ShrinkToFit is
turned on.

Basically, the DV reflows all the docs and then decides whether it needs to
reflow them again with a different shrink ratio, if so then the Presentation is
thrown away and they are reflowed and that is when the crash happens (the second
reflow for printing)

Comment 29

[Johnny Stenback (:jst)]

Attachment: Hack to fix the crash and the missing frames after printing...

Comment 30

[Johnny Stenback (:jst)]

The attached patch shows what the problem is and how it can be solved, but the
printing related API's don't allow for a clean way to solve this, so I'm
assigning this back to rods. Rod, I'm happy to help if there are more problems
here, but I'd like you to push this further and change the printing API's to
expose what's needed (i.e. a GetDoingPrinting() method, or something like that)
to let us fix this in a cleaner way.

Comment 31

[rods (gone)]

jst, your patch doesn't work. This was all caused by your check of moving IFrame
loading to content. I can help with this bug, but I am not familiar with all of
your changes yet.

Comment 32

[rods (gone)]

Attachment: patch

Patch so IFrames and Frame sets can print and print prview

Comment 33

[Johnny Stenback (:jst)]

This patch does work for me, I'm able to print home.netscape.com and it looks
right on paper. What isn't working for you, rods?

Comment 34

[rods (gone)]

Yes, my lastest patch that incorporates your changes and mine, seems to fix
everything from what I can tell.

Comment 35

[Johnny Stenback (:jst)]

Ok, great, but we're still not quite done. IMO this part of the diff is not a
clean fix:

@@ -8136,7 +8141,7 @@
 DocumentViewerImpl::GetDoingPrintPreview(PRBool *aDoingPrintPreview)
 {
   NS_ENSURE_ARG_POINTER(aDoingPrintPreview);
-  *aDoingPrintPreview = mIsDoingPrintPreview;
+  *aDoingPrintPreview = mIsDoingPrintPreview || mIsDoingPrinting;
 
   if (!*aDoingPrintPreview) {
     nsCOMPtr<nsIDocShellTreeItem> item(do_QueryInterface(mContainer));

This makes GetDoingPrintPreview() answer a different question than it was meant
to answer. We need to either renam the method, come up with an additional
method, or change the way we expose this information in the nsIWebBrowserPrint API.

Comment 36

[Christian :Biesinger (don't email me, ping me on IRC)]

crashes reproducably for me as part of the smoketests -> smoketest blocker
(trunk, 2002041908, linux)

Comment 37

[rods (gone)]

Actually, it can't be renamed. I think if needs to be just for PP, and a new IDL
attr added "doingPrinting".

Also, the method itself maybe incomplete. Intead of just checking the immediate
parent, it should walk all the way up. Becuase it could be an iframe in a frame
in a frameset.

Comment 38

[Johnny Stenback (:jst)]

The method does already walk up its parent chain, all the way up or until it
finds one that's in print preview mode.

Comment 39

[Dawn Endico]

Asa says to move this from smoketest blocker to critical since not all printing
is busted, just this one url that we happen to list on the smoketest page. (and
others in its class)

Comment 40

[rods (gone)]

Oops...Oh, ok. UI see that it is recursive.

Comment 41

[Johnny Stenback (:jst)]

Attachment: Better patch

Comment 42

[Johnny Stenback (:jst)]

Attachment: Better patch

Comment 43

[rods (gone)]

Comment on attachment 80067 [details] [diff] [review]
Better patch

I have applied the patch and tested it, it looks good.

Comment 44

[Tormod V]

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

Comment 45

[Johnny Stenback (:jst)]

Comment on attachment 80067 [details] [diff] [review]
Better patch

Rick says sr=rpotts

Comment 46

[Johnny Stenback (:jst)]

Fix checked in.

Comment 47

[sujay]

looks good to me in 4/23 trunk build..

Twalker will mark this verified after smoketesting for windows.

Comment 48

[sujay]

verified in 4/23 trunk build. I followed Daniel's steps above and
now I see the caret inside the style elements.

Comment 49

[rods (gone)]

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

Comment 50

[Jay Patel [:jay]]

Any chance that this fix will get onto the Mozilla1.0 branch?  Without it on the
branch, we'll most likely continue to see the crash logged in bug 138835.

Comment 51

[Johnny Stenback (:jst)]

This bug is about a trunk-only regression, if there are similar problems on the
branch, file a new bug.

Comment 52

[Tracy Walker [:tracy]]

this IS presnt on the 1.0.0 branch and it is on all platforms.

I believe writing a new bug for something that was passed onto the branch at the 
time of the branch is not the correct method of handling cross tree bugs.

reopening and changing summary

Comment 53

[Jay Patel [:jay]]

Tracy: Do you have the Talkback incidents from your Branch crashes?  I don't see
any crashes with the "DocumentViewerImpl::ReflowPrintObject" stack signature in
Mozilla1.0 branch data...so this crash might be showing up under a different
stack signature on the branch.  

I have verified that the "DocumentViewerImpl::ReflowPrintObject" crashes are no
longer happening on the Trunk as of 4/22.  See bug 138835.

Comment 54

[Johnny Stenback (:jst)]

This is so not present on the branch, open new bugs for printing problems on the
branch, this was about a trunk only regression that happened way after we branched.

Comment 55

[Tracy Walker [:tracy]]

the crash bug somehow swallowed the original bug that was written here waaay 
before before branching. The crash should have caused a new bug to be written. 
But whatever.

Comment 56

[Tracy Walker [:tracy]]

I am not seeing a *Crash*.\, so verifying.
139233 is open for branch behavior of failure to print home.netscape.com

Comment 57

[Simon Paquet [:sipaq]]

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

Comment 58

[Simon Paquet [:sipaq]]

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