A similar crash was fixed recently: bug 101746, but this stack signature is still showing up with recent MozillaTrunk builds...so logging a new bug. Here's the latest info from Talkback: nsTextFrame::TextStyle::TextStyle 74 101746 RESO FIXE hyatt@netscape.com mozilla0.9.6 2001-10-16 102778 RESO DUPL attinasi@netscape.com mozilla0.9.6 2001-10-07 BBID range: 37004020 - 37458573 Min/Max Seconds since last crash: 14 - 89398 Min/Max Runtime: 14 - 180862 Crash data range: 2001-10-22 to 2001-10-31 Build ID range: 2001102121 to 2001102911 Keyword List : button(4), load(8), browser(5), Stack Trace: nsTextFrame::TextStyle::TextStyle [d:\builds\seamonkey\mozilla\layout\html\base\src\nsTextFrame.cpp line 552] nsTextFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsTextFrame.cpp line 5020] nsLineLayout::ReflowFrame [d:\builds\seamonkey\mozilla\layout\html\base\src\nsLineLayout.cpp line 1038] nsBlockFrame::ReflowInlineFrame [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp line 3659] nsBlockFrame::DoReflowInlineFrames [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp line 3540] nsBlockFrame::DoReflowInlineFramesAuto [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp line 3465] nsBlockFrame::ReflowInlineFrames [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp line 3410] nsBlockFrame::ReflowLine [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp line 2479] nsBlockFrame::ReflowDirtyLines [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp line 2142] nsBlockFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp line 827] nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp line 737] CanvasFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLFrame.cpp line 570] nsBoxToBlockAdaptor::Reflow [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp line 891] nsBoxToBlockAdaptor::DoLayout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp line 540] nsBox::Layout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp line 1002] nsScrollBoxFrame::DoLayout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsScrollBoxFrame.cpp line 392] nsBox::Layout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp line 1002] nsContainerBox::LayoutChildAt [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsContainerBox.cpp line 653] nsGfxScrollFrameInner::LayoutBox [d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp line 1027] nsGfxScrollFrameInner::Layout [d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp line 1138] nsGfxScrollFrame::DoLayout [d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp line 1035] nsBox::Layout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp line 1002] nsBoxFrame::Reflow [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp line 944] nsGfxScrollFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp line 753] nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp line 737] ViewportFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsViewportFrame.cpp line 576] PresShell::InitialReflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp line 2700] HTMLContentSink::StartLayout [d:\builds\seamonkey\mozilla\content\html\document\src\nsHTMLContentSink.cpp line 3917] HTMLContentSink::DidBuildModel [d:\builds\seamonkey\mozilla\content\html\document\src\nsHTMLContentSink.cpp line 2756] CNavDTD::DidBuildModel [d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp line 669] nsParser::DidBuildModel [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp line 1384] nsParser::Terminate [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp line 1458] nsHTMLDocument::StopDocumentLoad [d:\builds\seamonkey\mozilla\content\html\document\src\nsHTMLDocument.cpp line 843] DocumentViewerImpl::Stop [d:\builds\seamonkey\mozilla\content\base\src\nsDocumentViewer.cpp line 1240] nsDocShell::Stop [d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp line 2279] nsDocShell::Destroy [d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp line 2424] nsWebShell::Destroy [d:\builds\seamonkey\mozilla\docshell\base\nsWebShell.cpp line 1412] nsHTMLFrameInnerFrame::~nsHTMLFrameInnerFrame [d:\builds\seamonkey\mozilla\layout\html\document\src\nsFrameFrame.cpp line 697] nsHTMLFrameInnerFrame::`scalar deleting destructor' nsFrame::Destroy [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrame.cpp line 471] nsFrameList::DestroyFrames [d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp line 131] nsContainerFrame::Destroy [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp line 135] nsFrameList::DestroyFrames [d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp line 131] nsContainerFrame::Destroy [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp line 135] nsFrameList::DestroyFrames [d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp line 131] nsContainerFrame::Destroy [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp line 135] nsLineBox::DeleteLineList [d:\builds\seamonkey\mozilla\layout\html\base\src\nsLineBox.cpp line 292] nsBlockFrame::Destroy [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp line 329] nsFrameList::DestroyFrames [d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp line 131] nsContainerFrame::Destroy [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp line 135] nsFrameList::DestroyFrames [d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp line 131] nsContainerFrame::Destroy [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp line 135] nsBoxFrame::Destroy [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp line 1172] nsFrameList::DestroyFrames [d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp line 131] nsContainerFrame::Destroy [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp line 135] ViewportFrame::Destroy [d:\builds\seamonkey\mozilla\layout\html\base\src\nsViewportFrame.cpp line 157] FrameManager::Destroy [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp line 458] PresShell::Destroy [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp line 1734] DocumentViewerImpl::Destroy [d:\builds\seamonkey\mozilla\content\base\src\nsDocumentViewer.cpp line 1224] Source File : http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/html/base/src/nsTextFrame.cpp line : 552 (37440408) URL: www.cnn.com (37414020) URL: www.slashdot.org (37414020) Comments: Opened a link in a new tab. As the new tab was loading I right-clicked on the tabl and chose "Close Tab". The browser proceeded to die. (37412032) URL: http://www.slashdot.org/ (37412032) Comments: I started chofmann's browser buster in a new tab then selected Close Other Tabs from another tab while a page was loading. (37388042) Comments: Switching off javascript for browser support in the preferences. (37355109) URL: http://news.bbc.co.uk (37355109) Comments: Loading the web page...Also using tabs but news.bbc.co.uk was the only page loading at the time and it was the selected tab (37341950) URL: http://www.del.dennon.com (37341950) Comments: My son hit the F9 key a bunch of times while one of the sidebars was trying to load. (37338834) URL: www.cnn.com (37331574) Comments: I create a new tab with ctrl+t and on new tab I go to bookmark (37324999) URL: www.cnn.com (37324999) Comments: trying to surf thru www.subdimension.com/nettools/anonymizit/index.shtml (37324770) URL: www.cnn.com (37289101) URL: www.cnn.com (37288912) URL: www.cnn.com (37288912) Comments: surfing thru www.subdimension/nettools/anonymizit/index.shtml (37286630) URL: http://tim.oreilly.com/sci-fi/herbert (37273374) Comments: Closed Tab (37233900) URL: news.bbc.co.uk (37187351) Comments: pushing back button continuosly. All the pages in the history were identical and had frames. (37186931) Comments: in "edit" - "preferences" - "navigaotor" - "tabbed browsing"tried to mark for "Load links in the background" and "Control+Enter in the URL bar" Clicked "OK" - and that's what was not considered ok from Mozilla )-:CheersArnvid (37169240) Comments: Crash when closing sidebar via F9 while HTML 4.01 sidebar was loading (37159398) Comments: setting font preferencies disallowing sites to use other fonts (37157744) Comments: nothing [:)] (37137838) URL: http://search.netscape.com (37137838) Comments: Just clicked on the Search button in the browser's UI. (37137615) URL: . (37137615) Comments: Just closing the browser. (37135436) Comments: Clicked on a bugzilla link to bring a window to the front. (37134926) URL: . (37134926) Comments: Pressed the search button. (37134517) URL: . (37134517) Comments: Just loading www.netflix.com (37110470) URL: http://www.rbc.ru (37108632) URL: www.mozilla.org (37108632) Comments: Just typed 'mozilla.org' in and hit enter. (37100096) URL: microsoft.com (37100096) Comments: I was browsing MS's site (in a tab). I clicked a link and before the page was done loading I blicked the back button. Disk grind then moz crashes. there was nothing special on the site that may have caused it so it looks like it's Moz's fault that the (37100096) Comments: actual HTML. (37078953) URL: http://news.bbc.co.uk (37075088) URL: http://news.bbc.co.uk If this is a regression of fixed bug 101746, please feel free to mark this a dup and reopen that one. Cc'ing some people from that bug...

adding crash, topcrash keywords and reassigning to hyatt.

Might actually be another manifestation of bug 103997 -- StartLayout() is kicking off during destruction as per Marc's comments of 2001-10-11 17:46 in that bug.

See also bug 104804.

*** Bug 110209 has been marked as a duplicate of this bug. ***

*** Bug 109256 has been marked as a duplicate of this bug. ***

Early M096 branch reports show six incidents in 2001111413 and 1617 builds. Updating summary. No comments.

*** Bug 111147 has been marked as a duplicate of this bug. ***

A good place to crash, http://netscape.businessweek.com, then click on the tab.

*** Bug 111741 has been marked as a duplicate of this bug. ***

This is the #3 topcrasher for Mozilla 0.9.6 and is also a topcrasher for the MozillaTrunk. I'm attaching complete Talkback topcrash reports so people can look into this. The target milestone is set to mozilla1.1 ...are we sure we want to wait until then to fix such a common crash?

The user comments refer to a number of user actions, but the crash is deep in layout code, although the code is largely unchanged for a long time. Perhaps some other change exposed a latent bug. Reassigning to default layout owner. top crash and all...

getting into current milestone

*** Bug 112828 has been marked as a duplicate of this bug. ***

I get a different stack, and it definitely points to a know problem where we are StartLayout is kicked off during destruction (as rbs commented). Like bug 103997, this is related to the way we handle frames in the layout rather than the content, and will be fixed bu jst's fix to bug 52334. This is probably a 'dup' of 52334, in the sense that fixing that will fix this. Marking depends-on for now. Here is the stack I got on http://netscape.businessweek.com (clicked a tab): NTDLL! 77fa018c() nsWindow::Create(nsWindow * const 0x05ac3e34, nsIWidget * 0x041269a4, const nsRect & {...}, nsEventStatus (nsGUIEvent *)* 0x02ea45e0 HandleEvent(nsGUIEvent *), nsIDeviceContext * 0x04126cd0, nsIAppShell * 0x00000000, nsIToolkit * 0x00000000, nsWidgetInitData * 0x0012eb40) line 1210 nsView::CreateWidget(nsView * const 0x05ac23e0, const nsID & {...}, nsWidgetInitData * 0x0012eb40, void * 0x00000000, int 1, int 1) line 911 nsScrollPortView::CreateScrollControls(nsScrollPortView * const 0x05ac2440, void * 0x00000000) line 177 nsScrollBoxFrame::CreateScrollingView(nsIPresContext * 0x04127d70) line 309 nsScrollBoxFrame::Init(nsScrollBoxFrame * const 0x04ec140c, nsIPresContext * 0x04127d70, nsIContent * 0x03fe5090, nsIFrame * 0x04ec11ac, nsIStyleContext * 0x04d19290, nsIFrame * 0x00000000) line 115 nsCSSFrameConstructor::InitAndRestoreFrame(nsIPresContext * 0x04127d70, nsFrameConstructorState & {...}, nsIContent * 0x03fe5090, nsIFrame * 0x04ec11ac, nsIStyleContext * 0x04d19290, nsIFrame * 0x00000000, nsIFrame * 0x04ec140c) line 6515 + 32 bytes nsCSSFrameConstructor::BeginBuildingScrollFrame(nsIPresShell * 0x041276b0, nsIPresContext * 0x04127d70, nsFrameConstructorState & {...}, nsIContent * 0x03fe5090, nsIStyleContext * 0x04ec1118, nsIFrame * 0x04ec1064, nsIAtom * 0x005795f0, nsIDocument * 0x05783ad0, int 1, nsIFrame * & 0x04ec11ac, nsCOMPtr<nsIStyleContext> & {...}, nsIFrame * & 0x00000000, nsIFrame * 0x00000000) line 5 nsCSSFrameConstructor::ConstructRootFrame(nsCSSFrameConstructor * const 0x04126860, nsIPresShell * 0x041276b0, nsIPresContext * 0x04127d70, nsIContent * 0x03fe5090, nsIFrame * & 0x00000000) line 3689 StyleSetImpl::ConstructRootFrame(StyleSetImpl * const 0x04126930, nsIPresContext * 0x04127d70, nsIContent * 0x03fe5090, nsIFrame * & 0x00000000) line 1397 + 39 bytes PresShell::InitialReflow(PresShell * const 0x041276b0, int 16665, int 12435) line 2663 HTMLContentSink::StartLayout() line 3932 HTMLContentSink::DidBuildModel(HTMLContentSink * const 0x0577e320, int 0) line 2769 CNavDTD::DidBuildModel(CNavDTD * const 0x0459b040, unsigned int 2152596471, int 1, nsIParser * 0x05781f00, nsIContentSink * 0x0577e320) line 666 + 14 bytes nsParser::DidBuildModel(unsigned int 2152596471) line 1387 + 55 bytes nsParser::Terminate() line 1472 nsHTMLDocument::StopDocumentLoad(nsHTMLDocument * const 0x05783ad0) line 849 DocumentViewerImpl::Stop(DocumentViewerImpl * const 0x05787840) line 1324 nsDocShell::Stop(nsDocShell * const 0x057354b0, unsigned int 3) line 2297 nsDocShell::Destroy(nsDocShell * const 0x057354b4) line 2442 nsWebShell::Destroy(nsWebShell * const 0x057354b4) line 1412 nsHTMLFrameInnerFrame::~nsHTMLFrameInnerFrame() line 700 nsHTMLFrameInnerFrame::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsFrame::Destroy(nsFrame * const 0x04de5b54, nsIPresContext * 0x0557dd70) line 479 + 52 bytes nsFrameList::DestroyFrames(nsIPresContext * 0x0557dd70) line 131 nsContainerFrame::Destroy(nsContainerFrame * const 0x04de5b14, nsIPresContext * 0x0557dd70) line 135 nsFrameList::DestroyFrames(nsIPresContext * 0x0557dd70) line 131 nsContainerFrame::Destroy(nsContainerFrame * const 0x04de5898, nsIPresContext * 0x0557dd70) line 135 nsLineBox::DeleteLineList(nsIPresContext * 0x0557dd70, nsLineList & {...}) line 292 nsBlockFrame::Destroy(nsBlockFrame * const 0x04de5580, nsIPresContext * 0x0557dd70) line 327 + 16 bytes nsFrameList::DestroyFrame(nsIPresContext * 0x0557dd70, nsIFrame * 0x04de5580) line 217 CanvasFrame::RemoveFrame(CanvasFrame * const 0x04de4f08, nsIPresContext * 0x0557dd70, nsIPresShell & {...}, nsIAtom * 0x00000000, nsIFrame * 0x04de5580) line 370 FrameManager::RemoveFrame(FrameManager * const 0x055494c0, nsIPresContext * 0x0557dd70, nsIPresShell & {...}, nsIFrame * 0x04de4f08, nsIAtom * 0x00000000, nsIFrame * 0x04de5580) line 857 nsCSSFrameConstructor::ReconstructDocElementHierarchy(nsCSSFrameConstructor * const 0x05531ea0, nsIPresContext * 0x0557dd70) line 7183 + 61 bytes StyleSetImpl::ReconstructDocElementHierarchy(StyleSetImpl * const 0x05533b20, nsIPresContext * 0x0557dd70) line 1404 PresShell::ReconstructFrames() line 5223 + 41 bytes PresShell::StyleSheetAdded(PresShell * const 0x05530d38, nsIDocument * 0x05560210, nsIStyleSheet * 0x05aed1f0) line 5235 nsDocument::InsertStyleSheetAt(nsDocument * const 0x05560210, nsIStyleSheet * 0x05aed1f0, int 0, int 1) line 1389 CSSLoaderImpl::InsertSheetInDoc(nsICSSStyleSheet * 0x05aed1f0, int 0, nsIContent * 0x0576b7c0, int 1, nsICSSLoaderObserver * 0x00000000) line 1164 CSSLoaderImpl::SheetComplete(nsICSSStyleSheet * 0x05aed1f0, SheetLoadData * 0x0576b5d0) line 867 CSSLoaderImpl::ParseSheet(nsIUnicharInputStream * 0x05aeb630, SheetLoadData * 0x0576b5d0, int & 1, nsICSSStyleSheet * & 0x05aed1f0) line 922 CSSLoaderImpl::DidLoadStyle(nsIStreamLoader * 0x0576b4f0, nsString * 0x05aeb270, SheetLoadData * 0x0576b5d0, unsigned int 0) line 957 + 27 bytes SheetLoadData::OnStreamComplete(SheetLoadData * const 0x0576b5d0, nsIStreamLoader * 0x0576b4f0, nsISupports * 0x00000000, unsigned int 0, unsigned int 3784, const char * 0x04df9e40) line 714 nsStreamLoader::OnStopRequest(nsStreamLoader * const 0x0576b4f4, nsIRequest * 0x05733810, nsISupports * 0x00000000, unsigned int 0) line 137 nsHttpChannel::OnStopRequest(nsHttpChannel * const 0x05733814, nsIRequest * 0x04713794, nsISupports * 0x00000000, unsigned int 0) line 2316 nsOnStopRequestEvent::HandleEvent() line 177 nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x04c7c6e4) line 80 PL_HandleEvent(PLEvent * 0x04c7c6e4) line 590 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x004fc970) line 520 + 9 bytes _md_EventReceiverProc(HWND__ * 0x009e0160, unsigned int 49687, unsigned int 0, long 5228912) line 1071 + 9 bytes USER32! 77e12e98() USER32! 77e130e0() USER32! 77e15824() nsAppShellService::Run(nsAppShellService * const 0x00539480) line 303 main1(int 1, char * * 0x00481880, nsISupports * 0x00000000) line 1304 + 32 bytes main(int 1, char * * 0x00481880) line 1630 + 37 bytes mainCRTStartup() line 338 + 17 bytes

I wonder if that http://netscape.businessweek.com link is unrelated to this. (Also, note that bug 112886 has the same stack that I found on http://netscape.businessweek.com). I think it is unrelated because the stacks differ, and I cannot dup the problem on any of the URLs listed in the talkbacks. The reported stack looks to be croaking around here: deviceContext->GetMetricsFor(*plainFont, langGroup, mNormalFont); aRenderingContext.SetFont(mNormalFont); mNormalFont->GetSpaceWidth(mSpaceWidth); mAveCharWidth = 0; #if defined(_WIN32) || defined(XP_OS2) mNormalFont->GetAveCharWidth(mAveCharWidth); #endif so I am wondering if this is a case of GetMetricsFor setting mNormalFont to null (I seem to remember this case happening before but the details escape me). I'd like to bullet-proof thi method and see if that helps, any comments on that?

Proposed wallpaper for the stacks in the talkback. I cannot dup this, but I think I have seen this problem before, and anyway the code is not checking for nulls here (though it may be that it should not ever get nulls).

Noting the uncertainty of the dependence on bug 52334 (with a '?' in summary).

Might also be related to bug 105619. When I hit this crash, the nsFont.name string (and the entire font struct is general) from the Style System is garbage.

The other "font" related bug it could possibly tied to would be bug 108939.

Crap. Ingore that. This bug is older than that. Sorry for the spam.

This seems like a duplicate of bug 104804. See also http://bugzilla.mozilla.org/show_bug.cgi?id=101554#c26

I've added a URL that crashed for me 100% with today's trunk win32 build. http://info.netscape.com/fwd/bnwooobwkh1/http://netscape.businessweek.com:80/tec hnology/tc_special/rethink_tech.htm

Stephen, that URL you posted crashes me too, but with the stack I posted in comment http://bugzilla.mozilla.org/show_bug.cgi?id=108105#c15 Fortunately, I have a fix for that cookin' now. If JST finishes his work on bug 52334 it will not be necessary, but I figured it was good insurance to take care of the problem in layout in case he didn't finish before 0.9.7 closed. Patch soon (for the 'other' crash at comment #15).

This patch fixes the 'other' stack, where we are trying to layout an IFRAME after it has been destroyed. It is a simple check to see if the WebShell is being destroyed (that was already a protected memeber of DocShell, I just exposed it) and avoid doing starting layout if it is. This is the least intrusive way I could think to fix this terrible architectural problem where stopping a document load because and IFRAME is being destroyed will synchronously causes a document to be built and layout to be initiated.

Updating summary...

Patch looks fine to me, although I wonder whether this really belongs on nsIWebShell, or whether it should be on nsIDocShell or something else.

Comment on attachment 60552 [details] [diff] [review] PATCH to prevent crash when an IFrame is being destroyed during layout r=dbaron, except I think you should ask a docshell owner (adamlock? rpotts?) on what interface this should really be (and you still have my r= if you move the same thing to another interface and/or to nsDocShell at their request)

nsIWebShell is an evil interface. It's probably better to go on nsIDocShell and be implemented by the nsDocShell class. Otherwise the patch looks fine in principle, though it would be better to use NS_ENSURE_ARG_POINTER in the pointer check for IsBeingDestroyed.

OK, I'll move it to nsIDocShell. I don't understand the difference between the interfaces anyway, but I'll assume you guys do ;)

Comment on attachment 60711 [details] [diff] [review] Patch: moves the new call to nsIDocShell instead of nsIWebShell dbaron said his review still applies

Comment on attachment 60711 [details] [diff] [review] Patch: moves the new call to nsIDocShell instead of nsIWebShell sr=jst

Patches checked in (including the null-check wallpaper). Checking in base/nsDocShell.cpp; /cvsroot/mozilla/docshell/base/nsDocShell.cpp,v <-- nsDocShell.cpp new revision: 1.394; previous revision: 1.393 Checking in base/nsIDocShell.idl; /cvsroot/mozilla/docshell/base/nsIDocShell.idl,v <-- nsIDocShell.idl new revision: 1.59; previous revision: 1.58 Checking in nsHTMLContentSink.cpp; /cvsroot/mozilla/content/html/document/src/nsHTMLContentSink.cpp,v <-- nsHTMLContentSink.cpp new revision: 3.507; previous revision: 3.506 Checking in nsTextFrame.cpp; /cvsroot/mozilla/layout/html/base/src/nsTextFrame.cpp,v <-- nsTextFrame.cpp new revision: 1.341; previous revision: 1.340

>Checking in nsTextFrame.cpp; >/cvsroot/mozilla/layout/html/base/src/nsTextFrame.cpp,v <-- nsTextFrame.cpp >new revision: 1.341; previous revision: 1.340 This one doesn't look like it will help. If a crash were to happen, the null check there would just be delaying it (since mNormalFont is required later on for measurements/painting). Seems the correct fix had made the check unnecessary.

verified fixed. the haven't been any crashes since 12/6 according to the latest talkback data.