134769 - Hidden FrameSet Frames causes crash after Print Preview - Trunk [@ nsDocument::~nsDocument]

Status: VERIFIED FIXED

(Core :: Print Preview, defect)

Description

[Dom Incollingo]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+)
Gecko/20020329
BuildID:    2002032916

Print preview crashes Mozilla at http://www.s1.com/ if landscpape mode is chosen
and the refresh (Reload) button is selected after the print preview window is
closed.

Reproducible: Always
Steps to Reproduce:
1.Navigate to http://www.s1.com/
2.Choose File / Print Preview
3.Click on the Landscape button (in the print preview menu bar)
4.Close print preview (click on the Close buton in the print preview menu bar).
5.Click on the Reload button (on the browser toolbar)
6.Mozilla crashes.

Expected Results:  Mozilla should not crash.

Please see talkback incident TB4713856Q.  Using Mozilla build 2002032916 on Win 2K.

Earlier in the day, I tried using build 2002040103.  Same result: crash. 
Talkback incident TB4710881W.

Comment 1

[Adam Hauner]

Stephen, should I ask you for TB4710881W?

Comment 2

[[e-mail] (gone - use [e-mail] instead)]

0x00030005
nsDocument::~nsDocument
[d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp, line 493]
nsHTMLDocument::~nsHTMLDocument
[d:\builds\seamonkey\mozilla\content\html\document\src\nsHTMLDocument.cpp, line 372]
nsHTMLDocument::`scalar deleting destructor'
nsDocument::Release
[d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp, line 601]
nsHTMLDocument::Release
[d:\builds\seamonkey\mozilla\content\html\document\src\nsHTMLDocument.cpp, line 376]
nsCOMPtr_base::~nsCOMPtr_base
[d:\builds\seamonkey\mozilla\xpcom\glue\nsCOMPtr.cpp, line 65]
PresShell::`scalar deleting destructor'
nsCOMPtr_base::assign_with_AddRef
[d:\builds\seamonkey\mozilla\xpcom\glue\nsCOMPtr.cpp, line 74]
nsCOMPtr_base::assign_with_AddRef
[d:\builds\seamonkey\mozilla\xpcom\glue\nsCOMPtr.cpp, line 70]
nsDocShell::Destroy [d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp,
line 2622]
0x088b0674 

Comment 3

[Karl Johan Kleist]

WFM. Build ID: 2002 03 27 08. Windows 2000. Default printer, if that matters:
"HP LaserJet 4050 Series PCL 6"

Comment 4

[Olivier Cahagne]

This is a dupe of bug 127639. I think we should reopen bug 127639.

Comment 5

[Dom Incollingo]

Not sure if this is a dupe of bug 127639 (which I also reported).  In bug
127639, Mozilla was crashing when I tried to open the print preview window.  I
was not able to successully open the print preview window or to print the page.

I am now able to open the print preview page and to print the screen.   The
crash in but 134769 occurs after I close the print preview window and click on
the browser's Reload button.

Comment 6

[Dom Incollingo]

I tried duplicating this bug using Mozilla 0.9.9 monthly build running on a
different computer (Win NT).  I went to http://www.s1.com/, selected print
preview, clicked on the landscape icon, closed print preview, and clicked the
Reload button.  Mozilla does not crash in 0.9.9.  However, clicking on the
landscape button causes the print preview screen image to disappear - a blank
white screen is displayed.  (I also reported this problem as bug 128171).

In build 2002032916, the problem with landscape orientation (bug 128171) has
been resolved.   The screen image displays correctly in print preview landscape
mode.  But the browswer crashes when print preview is closed and Reload is selected.

Comment 7

[Andrew Hagen]

Reporter, in comment 5 you say, "I am now able to open the print preview page
and to print the screen." Do you mean you printed the screen? Or do you mean you
printed the page?

Comment 8

[Dom Incollingo]

Attachment: This is how the browser rendered the site before I chose Print Preview.

Comment 9

[Dom Incollingo]

Attachment: This is how the site was displayed after I chose Print Preview and hit the Landscape button.

Comment 10

[Dom Incollingo]

Attachment: This is how the site was displayed in Print Preview window after I hit the Print button.

Comment 11

[Dom Incollingo]

Perhaps some pictures can help explain this.   Here is what I did:

1) Navigated to http://www.s1.com/.  Attachment id 77357 shows how the site
rendered.

2) Chose File / Print Preview.
  
3) Clicked on the Landscape button while in the Print Preview window. 
Attachment id 77358 shows how the image in the Print Preview window rendered
after I hit the Landscape button.

4) Pressed the Print button in the upper left corner of the Print Preview window.

5) AFTER I hit the Print button, I used the scroll bar in the Print Preview
window to scroll down slightly.  I then noticed that the word "Error 404"
appeared in the upper left of the image in the Print Preview window.  Attachment
id 77359 illustrates.  The "Error 404" did NOT appear until I pressed the Print
button.  Despite the "Error 404", the page did print correctly, although it
printed as two sheets of paper.  The first sheet simply contained the "Error
404" message; the second sheet contained the image of the web page. 

6) Pressed the Close button in the upper right of the Print Preview window.  The
Print Preview window closed and the browser window displayed.

7) Pressed the Reload button in the browser window.

8) The browser crashed.  Please see TalkBack incident #TB4754489Q.

I tried this procedure three times, and the browser crashed all three times.

Also, please note the bar graph that displayed in the original browser window
(attachment 77357 [details]).  This graph did not appear in the Print Preview window
(attachments 77358 and 77359).  However, this bar graph DID print on my hardcopy
after I hit the Print button in the Print Preview window.  

Finally, I tried retesting without actually printing the page: i.e., I followed
the procedure listed above but SKIPPED steps 4 and 5.  I tried this three times,
but the browser crashed on only one of the three tests.  Please see TalkBack
incident #TB4754569M. 


All tests conducted today used build 2002040203 on Win 2K.

Comment 12

[Jay Patel [:jay]]

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

Comment 13

[Jay Patel [:jay]]

I was able to crash using the steps mentioned in comment #0.  I was also able to
crash without refreshing the page (I think):

 Incident ID 4797470   Stack Signature  0x00000080 8867c2e9
Trigger Time 2002-04-03 17:34:28
Email Address [e-mail]
URL visited http://www.s1.com/
Build ID 2002040210
Product ID MozillaTrunk
Platform
Operating System Win32
Module
Trigger Reason Access violation
User Comments i don't know...i did a print preview and then didn't reload like
last time...i just closed the tab...and went to open mail. trunk builds have
sucked for the last few days...
Stack Trace
0x00000080
nsDocument::~nsDocument
[d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp, line 493]
nsHTMLDocument::~nsHTMLDocument
[d:\builds\seamonkey\mozilla\content\html\document\src\nsHTMLDocument.cpp, line 372]
nsHTMLDocument::`scalar deleting destructor'
nsDocument::Release
[d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp, line 601]
nsHTMLDocument::Release
[d:\builds\seamonkey\mozilla\content\html\document\src\nsHTMLDocument.cpp, line 376]
nsDOMEvent::~nsDOMEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsDOMEvent.cpp, line 270]
nsWebShell::QueryInterface
[d:\builds\seamonkey\mozilla\docshell\base\nsWebShell.cpp, line 266]
0x04050b55 

Either way, this is definitely a problem.  Confirming to New. Adding testcase,
topcrash+ keywords and nominating for nsbeta1.

Comment 14

[Jay Patel [:jay]]

Adding Trunk [@ nsDocument::~nsDocument] to summary for tracking.  This is
showing up under the nsDocument::~nsDocument stack signature as well as
different 0xXXXXXXXX addresses in Talkback data.

Comment 15

[Jay Patel [:jay]]

The steps to reproduce this are fairly simple...here is my latest crash with
today's build:

 Incident ID 4839921   
Stack Signature  nsDocument::~nsDocument b6cfb46e
Trigger Time 2002-04-04 19:14:06
Email Address [e-mail]
URL visited http://www.s1.com/
Build ID 2002040411
Product ID MozillaTrunk
Platform
Operating System Win32
Module
Trigger Reason Access violation
User Comments 1. went to http://www.s1.com/ 2. print preview 3. close print
preview 4. reload http://www.s1.com/ page. 5. crash! It's that simple for me
with today's build.
Stack Trace
nsDocument::~nsDocument
[d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp, line 493]
nsHTMLDocument::~nsHTMLDocument
[d:\builds\seamonkey\mozilla\content\html\document\src\nsHTMLDocument.cpp, line 376]
nsHTMLDocument::`scalar deleting destructor'
nsDocument::Release
[d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp, line 601]
nsXMLDocument::Release
[d:\builds\seamonkey\mozilla\content\xml\document\src\nsXMLDocument.cpp, line 257]
nsDOMEvent::~nsDOMEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsDOMEvent.cpp, line 270]
nsWebShell::QueryInterface
[d:\builds\seamonkey\mozilla\docshell\base\nsWebShell.cpp, line 266]
0x0012fc08 

I don't think printing the page or changing the page orientation has any
effect...just closing print peview and reloading is enough to get a crash.

Comment 16

[Jay Patel [:jay]]

As it turns out...you don't even have to reload the page after closing the print
preview window.  I simply clicked the back button to get back to this bug (after
closing the print preview) and it crashed.  

Comment 17

[rods (gone)]

The s1 site has the height of the top frame in the frameset to 100% and the
second to '*'  rows="100%,*" this causes the second frame to be hidden. It's
beyond me why you would do this... But then frames with style set to
"visibility:hidden" crash also.

Comment 18

[rods (gone)]

Attachment: patch

Add a new attr to PrintObject for identifying POs that are to be hidden, not
reflowed. So if a frameset frame's root frame is zero height then we mark it
hidden and not to be printed. 

This patch also fixes a regression from 6.2 where when printing selection it
prints in the top margin of the second (or third, etc.) page.

It also removes some very unwanted printfs from the PrintPreviewListener.h

Comment 19

[rods (gone)]

I have tested frameset frames that are "hidden" and those that get not "row
height" from the frameset tag. I have test this also with all forms of print
preview and printing. And printing while in print preview.

Comment 20

[rods (gone)]

Attachment: new patch

The previous patch inclued a fix that just got checked in, this is a cleaner
patch. (See comments from previous patch)

Comment 21

[Shiva Thirumazhusai]

Do not remove the Stack Signature information. This is key for tracking topcrash
bugs.

Comment 22

[dcone (gone)]

Comment on attachment 78344 [details] [diff] [review]
new patch

I would like you to put parens around the binary ands...... I think there are 2
of them.
r=dcone

aFlags & eSetPrintFlag

Comment 23

[Marc Attinasi]

Comment on attachment 78344 [details] [diff] [review]
new patch

sr=attinasi

Comment 24

[rods (gone)]

Attachment: patch

Made changes ready for final review.

Comment 25

[rods (gone)]

Comment on attachment 78483 [details] [diff] [review]
patch

added patch to wrong bug

Comment 26

[rods (gone)]

Comment on attachment 78344 [details] [diff] [review]
new patch

This is the good patch, accidently added patch to a different bug

Comment 27

[Jaime Rodriguez, Jr.]

Pls land this on the trunk to bake for a few days, have QA look, and make sure
there are no regressions introduced, then come back to us for approval - ADT1

Comment 28

[Jaime Rodriguez, Jr.]

Removing adt1.0.0. Pls renominate, once this has landed on the trunk, and QA has
verified that this patch doesn't break us.

Comment 29

[Asa Dotzler [:asa]]

Comment on attachment 78344 [details] [diff] [review]
new patch

a=asa (on behalf of drivers) for checkin to the 1.0 branch

Comment 30

[rods (gone)]

fixed on trunk

Comment 31

[Kevin McCluskey (gone)]

sujay: Could you verify the fix on the trunk? Thanks!

Comment 32

[rods (gone)]

fxied

Comment 33

[sujay]

verified on 4/15 trunk build.

does not crash anymore.

Comment 34

[Jaime Rodriguez, Jr.]

adt1.0.0+ (on ADT's behalf) for checkin into the 1.0 branch. Pls check this in
to the branch today. After it is checked in, pls add fixed1.0.0. Once QA has
verified it on the branch, then add verified1.0.0.

Comment 35

[sujay]

verified on 4/17 branch build. adding "verified1.0.0" keyword