Closed Bug 1030843 Opened 10 years ago Closed 10 years ago

crash in nsNativeThemeCocoa::GetMinimumWidgetSize(nsRenderingContext*, nsIFrame*, unsigned char, nsIntSize*, bool*)

Categories

(Core :: Widget: Cocoa, defect)

33 Branch
All
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla33

People

(Reporter: rnewman, Assigned: jwatt)

References

Details

(Keywords: crash, reproducible)

Crash Data

Attachments

(2 files)

This bug was filed from the Socorro interface and is 
report bp-e05bb53e-5488-4b1b-8e17-86c8f2140626.
=============================================================

https://crash-stats.mozilla.com/report/index/e05bb53e-5488-4b1b-8e17-86c8f2140626

Nightly, retina MBP. Crash when printing a page to PDF.

Looks just like Bug 877085.
Component: Layout → Widget: Cocoa
I haven't been able to reproduce this yet, but the first report appears to show a build of 6/21/2014. This might be a recent regression and unrelated to bug 877085.
Ditto :-)

These appear to have started very recently (the earliest report I can find is for the 2014-06-21 m-c nightly).

I can't reproduce these.  Since it seems that you can, Richard, can you find the regression range (in m-c nightlies)?
This only happens for my personal profile. Even copying my prefs.js into another profile (which should mean the same gfx and print settings) doesn't allow for repro.

I'll try to get a regression range the hard way.
I was able to reproduce with an older profile. Let me see what I can find out. A regression range would still be much appreciated.
2014-06-18 Nightly doesn't crash.
Oh, that was pretty easy. This was caused by the fix for bug 1027645.

aFrame is NULL here:
http://hg.mozilla.org/mozilla-central/annotate/aab918af0f9c/widget/cocoa/nsNativeThemeCocoa.mm#l3226
Blocks: 1027645
Attached file callstack.txt
Fits with the next interval in my manual regression search -- 20140623030201 crashes. Great!
Attached patch patchSplinter Review
I'm not sure that it really makes sense to be asking for a minimum size with no frame, but I guess it could do. It seems the nsRenderingContext argument isn't actually used other than to get unit conversion ratios, so we might as well change it to an nsPresContext argument instead. That happens to allow us to stop needlessly creating nsRenderingContexts in a couple of locations as an added bonus.
Assignee: nobody → jwatt
Attachment #8446698 - Flags: review?(roc)
I should also update NS_ITHEME_IID and NS_THEMERENDERER_CID of course. Done locally.
https://hg.mozilla.org/mozilla-central/rev/97220529a789
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: