Closed Bug 151607 Opened 22 years ago Closed 22 years ago

Attempting to print netscape.com page results in crash [@ DocumentViewerImpl::DonePrintingPages]

Categories

(Camino Graveyard :: General, defect)

PowerPC
macOS
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: chrispetersen, Assigned: bryner)

References

Details

(Keywords: crash, Whiteboard: [adt2 RTM] [ETA 06/28])

Crash Data

Attachments

(6 files)

Build: 2002-06-13-05 NB
Platform: OS X 10.1.5
Expected Results: No error should appear nor should the application crash.
What I got: Application crashes after clicking OK in error sheet.

Steps to reproduce:

1) Go to netscape.com
2) Select Print from File menu.
3) Click Print in dialog
4) Error should occur. Click OK.
5) Application crashes.
This isn't just  restricted to netscape.com. This same problem happens with when
attempting to print a query from ebay and printing directions at mapquest.com.

Ebay:

http://search.ebay.com/search/search.dll?MfcISAPICommand=GetResult&ht=1&SortProperty=MetaEndSort&ebaytag1code=0&query=mac+iifx

BTW, the page actually does print though.
Attached file Stack trace
Severity: normal → major
Another of way of verifying this issue without actually printing the document is
to click the preview button in the Print dialog. This will create a pdf file and
launch the Preview app. When the pdf is displayed in Preview, chimera crashes.
Severity: major → critical
Keywords: crash
Summary: Attempting to print netscape.com page results in crash → Attempting to print netscape.com page results in crash [@ DocumentViewerImpl::DonePrintingPages]
Crash occurs after printing page on mapquest.com Page contains JS function
(htmlAdWH) which references additional functions in the external JS file. BTW,
this (htmlAdWH) function is used on the netscape page which also crashs after
printing.
In the test case, two script elements are contained in BODY element:

<body>
<script language="JavaScript1.1">
<!--

htmlAdWH('93121588', '120', '60');

//-->
</script>
<script language="JavaScript1.1">
<!--

htmlAdWH('93063405', '120', '60');

//-->
</script>
</body>

In order to reproduce the crash, both must be present. Perhaps these are being
executed after print job has been sent ?
Open test case and print page. Crash occurs.

Page contains two main elements:
* external JS file that creates a banner ad
* iframe element
->pinkerton, does anyone have any particular experience with printing?
Assignee: saari → pinkerton
This happens on ebay.com and mapquest.com
Blocks: 147975
beard does --> beard
Assignee: pinkerton → beard
I have just been testing Navigator's performance on Mapquest.com and I was able
to print driving directions to an HP 932c without any problems (twice). I am
using Mac OS X (10.1.5) and Navigator 0.3.0 (18 June).
I was able to print the http://netscape.com with a debug build, but my 
optimized build crashed with the same stack. I wonder if we have some 
debug specific logic going on here... 
I can look at this.
Assignee: beard → bryner
Attached file Yahoo webmail crashlog
This printing crash problem also occurs in yahoo webmail.  Attaching crash log.
When this error occurs, we crash in DocumentViewerImpl::DonePrintingPages
because mPrt is null.
Status: NEW → ASSIGNED
I think there's something odd going on with mPagePrintTimer.  We delete it and
the nsITimer is cancelled, but then its callback fires anyway...
Ok, that's not quite right.  The timer in question isn't being cancelled.  It
appears that the PagePrintTimer is having StartTimer called on it multiple
times, and the nsITimers that were "thrown away" are still managing to fire.

Rod, maybe you can give me some insight here.  Is it a bug if
StartPagePrintTimer is being called more than once?
Yes, it is, is this a Mac only problem?
I just tested it out on Windows and it is called a single time.
This problem only occurs in optimized Mac Mach-O builds, as far as I can tell.
I think this is an uninitialized variable problem:

When PrintDocContent() calls DoPrint() it does not initialize |donePrinting|. 
DoPrint() never sets this variable either.  On win32, it seems to happen to
receive a non-zero value such that |if (donePrinting)| evaluates to true and we
return from PrintDocContent.   On the mac mach-o build, donePrinting is 0 and we
fall into the second part of PrintDocContent which will result in DoPrint being
called again and us starting another timer.
Attached patch patchSplinter Review
This initializes donePrinting to PR_TRUE.

I think a cleaner fix might be to not check the value of donePrinting there at
all.  I don't see any way it could get set to false in DoPrint unless
mContainer has a null webshell, and I doubt we want to continue calling DoPrint
in that case.  Rod, what do you think?
Comment on attachment 89454 [details] [diff] [review]
patch

r=rods, extensive clean up later
Attachment #89454 - Flags: review+
Comment on attachment 89454 [details] [diff] [review]
patch

sr=sspitzer, given that rods did the r=.
Attachment #89454 - Flags: superreview+
Checked into the trunk and the chimera branch.  I'm nominating this for the 1.0
branch because this definitely has crash potential in Seamonkey as well, on all
platforms.  There are a fair number of talkback reports that have this stack:

http://climate.netscape.com/reports/incidenttemplate.cfm?bbid=7454063
http://climate.netscape.com/reports/incidenttemplate.cfm?bbid=7693588
http://climate.netscape.com/reports/incidenttemplate.cfm?bbid=7339972
http://climate.netscape.com/reports/incidenttemplate.cfm?bbid=7334751

and about 56 others, mostly on Linux, a few on Windows.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Blocks: 143047
Keywords: approval
Whiteboard: [adt2 RTM] [ETA 06/28]
adt1.0.1+ (on ADT's behalf) approval for checkin on the 1.0 branch, pending
drivers approval. pls check this in asap, then add the "fixed1.0.1" keyword.
Keywords: adt1.0.1adt1.0.1+
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.
Verified with 06-28 build on OS 10.1.5.

Tested original report, mapquest.com reduced test case in comment #6, ebay.com
reduced test case in comment #8, and yahoo webmail in comment #15.
Status: RESOLVED → VERIFIED
No longer blocks: 147975
Crash Signature: [@ DocumentViewerImpl::DonePrintingPages]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: