208920 - If the Print command is issued, the browser crashes

Status: VERIFIED FIXED

(Camino Graveyard :: Printing, defect)

Description

[david toub]

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
http://www.healthdatamanagement.com/html/current/PastIssueStory.cfm?PostID=14851&PastMonth=May&PastYear=2003
2. Select "Print" from the menu or hit command-P
3. Instant crash!

Actual Results:  
Crash

Expected Results:  
Printed the page and continued running

Talkback ID = TB280327Y

Comment 1

[Conrad Carlen (not reading bugmail)]

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.

Comment 2

[Chris Casciano]

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)

Comment 3

[Chris Casciano]

Attachment: crash log - print to pdf

full crash log entry mentioned in comment 2

Comment 4

[Chris Casciano]

just hit this again with print preview on
http://www.planete.tm.fr/progs/programmes.html

(testing bug 192243)

[sorry for the spam... but this bug is starting to hurt]

Comment 5

[Paul Constantine]

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.

Comment 6

[Paul Constantine]

I am now finding that it sometimes DOES make a PDF and other times does not. So
it looks to be an intermittent problem.

Comment 7

[Paul Constantine]

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).

Comment 8

[S Woodside]

Aha, I can finally reproduce this thanks to comment #4. A bigger list of URLs
that always crash, would be VERY USEFUL!

Comment 9

[dan.m]

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

Comment 10

[Ludovic Hirlimann [:Usul]]

Could this one be fixed for 0.8 ?

Comment 11

[Mark Knopper]

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.

Comment 12

[Paul Constantine]

Just tested with Build ID: 2003083002.

Tested with http://www.macintouch.com/

Camino crashes while generating PDF file.

Comment 13

[ashish]

could not reproduce the bug with  http://www.macintouch.com/
as Paul mentioned in comment #12 above. i am using Camino 2003081810 build. 

Comment 14

[david toub]

I'm running the 9/3 build, and yes, www.macintouch.com crashes Camino without
activating TalkBack if I try to print this page as PDF output. 

Comment 15

[Ben Fowler]

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.

Comment 16

[Paul Constantine]

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.

Comment 17

[Ben Harris]

I seem to get this pretty solidly on reiseauskunft.bahn.de (three times in
succession so far).  Steps to reproduce:

1: Go to http://reiseauskunft.bahn.de/
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.

Comment 18

[Ben Harris]

Attachment: Page that causes this crash

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

Comment 19

[Ben Harris]

Bah.  Ignore my comments.  Further tests show that the crash isn't reliable
there either.

Comment 20

[Mike Pinkerton (not reading bugmail)]

taking for 0.8

Comment 21

[S Woodside]

upgrading to blocker. more pages that cause the crash, test cases are helpful
thanks.

Comment 22

[Anne Dux]

Camino crashes when printing or previewing the following URL
http://tech.irt.org/articles/js152/
http://www.miswebdesign.com/resources/articles/handy-hints-web-design.html
http://www.bignosebird.com/gentech.shtml
Camino Build ID: 2003090102

Comment 23

[ashish]

i could reproduce the first & the last crash (see above mail by anne.dux),
Camino2003081810
===================================
here are those again:

http://tech.irt.org/articles/js152/
http://www.miswebdesign.com/resources/articles/handy-hints-web-design.html
http://www.bignosebird.com/gentech.shtml
===================================

Comment 24

[Mike Pinkerton (not reading bugmail)]

i took a look at this tonight with http://tech.irt.org/articles/js152/. 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

smfr?

Comment 25

[Dave Wells]

I found that if I go into the Camino print options and uncheck the "fit to page
width" setting (default?), it prints just fine.

Comment 26

[Chris Petersen]

Attachment: Reduced test case of http://tech.irt.org/articles/js152/

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.

Comment 27

[Mike Pinkerton (not reading bugmail)]

does it work if you change the image to a different image? could it be certain
images hork up the rendering context during printing?

Comment 28

[Paul Constantine]

Just tried the site I test with (macintouch.com). 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

Comment 29

[Chris Petersen]

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 Preview.app and
noticed it contained two frames (animated gif). So after this finding I
referenced other animated gifs found at macintouch and apple.com. 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)

Comment 30

[Chris Petersen]

Attachment: Same test case as before but using a animated gif found on macintouch.com

Comment 31

[Mina]

Confirming on basis of attachment of comment #30, NB Build ID: 2003100911

Comment 32

[david toub]

Using the 10/16 build, Camino crashes if you print
http://www.orthopedictechreview.com/issues/novdec02/case.htm

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.

Comment 33

[Mike Pinkerton (not reading bugmail)]

Attachment: final fixes from camino branch which fix bug

these are leftover changes from the camino branch which we never migrated from
the camino trunk. they also happen to fix this bug.

Comment 34

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 134747 [details] [diff] [review]
final fixes from camino branch which fix bug

need r/sr for changes leftover from camino branch.

Comment 35

[Simon Fraser [no longer active]]

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.

Comment 36

[Mike Pinkerton (not reading bugmail)]

simon, the patch to nsGFXUtils.h is the one that actually fixes this bug. What
should we do with the other patches here?

Comment 37

[Simon Fraser [no longer active]]

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.

Comment 38

[Conrad Carlen (not reading bugmail)]

Comment on attachment 134747 [details] [diff] [review]
final fixes from camino branch which fix bug

r=ccarlen

Comment 39

[Mike Pinkerton (not reading bugmail)]

landed.

Comment 40

[Chris Petersen]

Excellent !! Crash no longer occurs when attempting to print the attached test
cases. Marking verified fixed using the 2003111013 NB.