Closed Bug 208920 Opened 19 years ago Closed 19 years ago

If the Print command is issued, the browser crashes


(Camino Graveyard :: Printing, defect)

Not set


(Not tracked)



(Reporter: dtoub, Assigned: mikepinkerton)




(Keywords: crash)


(5 files)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021104 Chimera/0.6
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021104 Chimera/0.6

After loading this page, I cannot print it out or even save as a PDF through the
Print command, as it immediately crashes Camino 0.7 (the June 9th build). Using
a new Users folder does not solve the problem.

Reproducible: Always

Steps to Reproduce:
1.Go to
2. Select "Print" from the menu or hit command-P
3. Instant crash!

Actual Results:  

Expected Results:  
Printed the page and continued running

Talkback ID = TB280327Y
Confirming. Crashes for me with 20030610 build of Camino. Does not crash with
same build of Mozilla. Difference is the "Browser by Topic" <select> widget?
Also, does not crash with Camino 0.6.
Ever confirmed: true
confirming earlier reports... crashes Camino 2003061104 at what looks to be a
page into the print to PDF (as indicated by the progress meter), WFM Mozilla
2003061103.. TBID TB282018G

top 10 items in stack (full stack attached in a second):


Date/Time:  2003-06-12 09:49:34 -0400
OS Version: 10.2.6 (Build 6L60)
Host:       pnhTiObject.local.

Command:    Camino
PID:        458

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_INVALID_ADDRESS (0x0001) at 0xffffffff

Thread 0 Crashed:
 #0   0x91a58a98 in GetPMBaseAddr
 #1   0x91a94aa0 in BeginCGSContextForPixMapInternal
 #2   0x91a652a8 in BeginCGSContextForPortInternal
 #3   0x91a6b96c in BeginCGSContextForPort
 #4   0x969e3fbc in CreateAndSetupContext
 #5   0x96a47bf8 in DrawThemeButton
 #6   0x001ba38c in nsNativeThemeMac::DrawButton(unsigned short, Rect const&,
int, int, unsigned short, unsigned short, int)
 #7   0x001bb120 in nsNativeThemeMac::DrawWidgetBackground(nsIRenderingContext*,
nsIFrame*, unsigned char, nsRect const&, nsRect const&)
 #8   0x004fdfb0 in nsCSSRendering::PaintBackgroundWithSC(nsIPresContext*,
nsIRenderingContext&, nsIFrame*, nsRect const&, nsRect const&, nsStyleBackground
const&, nsStyleBorder const&, nsStylePadding const&, int)
 #9   0x004fdc94 in nsCSSRendering::PaintBackground(nsIPresContext*,
nsIRenderingContext&, nsIFrame*, nsRect const&, nsRect const&, nsStyleBorder
const&, nsStylePadding const&, int)
 #10  0x002dc158 in nsFrame::PaintSelf(nsIPresContext*, nsIRenderingContext&,
nsRect const&, int, int)
Severity: normal → critical
Keywords: crash
full crash log entry mentioned in comment 2
just hit this again with print preview on

(testing bug 192243)

[sorry for the spam... but this bug is starting to hurt]
Through Build ID: 2003071505, I see this bug... but pertaining more to trying to
Print to PDF. the application will either crash outright (TalkBacks sent if
available) or not crash but produce a blank PDF (i.e. zero byte pdf).

Matter not what page I'm on.

Never haqd this probolem crop up on "0.7 release" version. Has affected every
nightly that I've run. This IS a showstopper.
I am now finding that it sometimes DOES make a PDF and other times does not. So
it looks to be an intermittent problem.
FYI, verified that with the latest nightly (Build ID: 2003081202) it will work
correctly and it will crash the application. This is from a multipage site with
no javascript (Macintouch home page).
Aha, I can finally reproduce this thanks to comment #4. A bigger list of URLs
that always crash, would be VERY USEFUL!
Confirm crash at URL above, slight difference in behavior:

1. Load URL
2. Hit Command-P
3. Dialog pops up
4. Make your print selections
5. Hit OK - THEN app bombs...

Build ID: 2003082702
Could this one be fixed for 0.8 ?
This also crashes for me (same stack as in previous attachment) with Camino Build ID: 
2003090302 running under Panther 7B53, printing to an Epson 900N printer via IP printing.
Just tested with Build ID: 2003083002.

Tested with

Camino crashes while generating PDF file.
could not reproduce the bug with
as Paul mentioned in comment #12 above. i am using Camino 2003081810 build. 
I'm running the 9/3 build, and yes, crashes Camino without
activating TalkBack if I try to print this page as PDF output. 
This works for me with a home built debug version. I can open the
Macintouch page, and p;rint it to PDF.

I do, though, get this assertion failure:

###!!! ASSERTION: nsIPrintSettingsX::ReadPageFormatFromPrefs() failed:
'NS_SUCCEEDED(rv)', file ../../../../src/gfx/src/mac/nsPrintOptionsX.cpp, line 113
Break: at file ../../../../src/gfx/src/mac/nsPrintOptionsX.cpp, line 113

The PDF is saved OK, and looks  right in preview.
Thanks Ashish, David and Ben.

I am only using Macintouch because there doesn't appear to be any JavaScript
code to drive elements of that page, and that it's generally multi-page. This
behavior occurs on just about any page I visit.

As I said in another comment, this behavior is (unfortunately) intermittent.
With one specific build I was able to get a PDF generated correctly. A second
try (without a reboot) crashed the browser.
I seem to get this pretty solidly on (three times in
succession so far).  Steps to reproduce:

1: Go to
2: Choose "English"
3: Ask for trains from Cambridge to Plymouth on 06.09.03 arriving 18:00. (I
suspect other quuries work too; that's just the journey I wanted to make).
4: On the results page, hit Cmd+P, then Return.
Attempting to print this page seems to crash my Camino (Build ID: 2003090502)
reliably.  Instructions:

1: Open the page (I double-clicked on my saved copy)
2: Press Cmd-P, then Return
Bah.  Ignore my comments.  Further tests show that the crash isn't reliable
there either.
taking for 0.8
Assignee: ccarlen → pinkerton
Target Milestone: --- → Camino0.8
upgrading to blocker. more pages that cause the crash, test cases are helpful
Severity: critical → blocker
i could reproduce the first & the last crash (see above mail by anne.dux),
here are those again:
Blocks: 211313
i took a look at this tonight with we're
trying to draw a combobox and crashing with (maybe) a corrupted port. We hit the
combobox drawing code like 5 times, then switch grafports to a new one, then at
some point crash.

a) why do we hit this code 5 or 6 times for a page with only 1 combobox
b) how on earth can we figure out who is trashing the port

I found that if I go into the Camino print options and uncheck the "fit to page
width" setting (default?), it prints just fine.
This test case contains only a img element and input=submit element. Both have
to be present in order to reproduce the crash when attempting to print this
test case.
does it work if you change the image to a different image? could it be certain
images hork up the rendering context during printing?
Just tried the site I test with ( FYI, I do Print to PDF rather
than to my printer (Epson inkjet). Crashed. Tried deselecting "Shrink to Fit
Page Width." Crashed.

Build ID: 2003083002
Ok, I originally couldn't reproduce the crash when I referenced other gifs on
the test case. I looked at the gif that reproduced the crash in and
noticed it contained two frames (animated gif). So after this finding I
referenced other animated gifs found at macintouch and With either
animated gif I referenced, I can reproduce the crash when printing the test
case. So basically the documemnt must contain a animated gif and a input element
(using type=submit / value attributes)
QA Contact: winnie → chrispetersen
Confirming on basis of attachment of comment #30, NB Build ID: 2003100911
Using the 10/16 build, Camino crashes if you print

Not even if a PDF option is chosen, just with routine printing to a network
printer. The spooling occurs for a few pages, then the browser goes down.
these are leftover changes from the camino branch which we never migrated from
the camino trunk. they also happen to fix this bug.
Comment on attachment 134747 [details] [diff] [review]
final fixes from camino branch which fix bug

need r/sr for changes leftover from camino branch.
Attachment #134747 - Flags: superreview?(sfraser)
Attachment #134747 - Flags: review?(bryner)
Do we know which of these changes fixes the crash?
SetPortToKnownGoodPort() can call SetPort(NULL) on Mac OS X.
I think we should add an NS_ASSERTION() in the nsImageMac code when the port is
bad, to know when we hit that.
simon, the patch to nsGFXUtils.h is the one that actually fixes this bug. What
should we do with the other patches here?
Comment on attachment 134747 [details] [diff] [review]
final fixes from camino branch which fix bug

Let's keep the nsDeviceContextMac.cpp and nsGfxUtils.h changes.
Attachment #134747 - Flags: superreview?(sfraser) → superreview+
Comment on attachment 134747 [details] [diff] [review]
final fixes from camino branch which fix bug

Attachment #134747 - Flags: review?(bryner) → review+
Closed: 19 years ago
Resolution: --- → FIXED
Excellent !! Crash no longer occurs when attempting to print the attached test
cases. Marking verified fixed using the 2003111013 NB. 
You need to log in before you can comment on or make changes to this bug.