Closed Bug 151607 Opened 23 years ago Closed 23 years ago

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

Categories

(Camino Graveyard :: General, defect)

Product:
Camino Graveyard
Component:
General
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: chrispetersen, Assigned: bryner)

References

Details

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

Crash Data

Attachments

(6 files)

Stack trace
3.69 KB, text/plain
Details
Screen shot of error message
110.83 KB, image/gif
Details
Reduced test case from mapquest
434 bytes, text/html
Details
Reduced test case from ebay.com
554 bytes, text/html
Details
Yahoo webmail crashlog
3.97 KB, text/plain
Details
patch
628 bytes, patch
sspitzer
: superreview+
Details | Diff | Splinter Review
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 patch — — Splinter 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: 23 years ago
Keywords: adt1.0.1, mozilla1.0.1
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.1 → adt1.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.
Keywords: mozilla1.0.1 → mozilla1.0.1+
Keywords: mozilla1.0.1+ → fixed1.0.1
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: