abc.net.au topcrash

[GoogleCodeExporter]

With JavaScript. This appears to be due to one of the ad rotators.

Eventually this terminates in a frame destruction which naturally is null.

Bugs exonerated: this is not 348470.

Original issue reported on code.google.com by classi...@floodgap.com on 19 Aug 2009 at 3:38

[GoogleCodeExporter]

milestone fix

Original comment by classi...@floodgap.com on 19 Aug 2009 at 3:38

• Added labels: Milestone-Release9.0.4, Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Not repaired by my fix for Brian D's Alltopcrash in issue 41.

Original comment by classi...@floodgap.com on 19 Aug 2009 at 3:39

[GoogleCodeExporter]

Stack trace:
CSS2PropertiesTearoff::SetDisplay(const nsAString&)
nsDOMCSSDeclaration::SetProperty(const nsAString&,const nsAString&,const 
nsAString&)
nsDOMCSSAttributeDeclaration::ParsePropertyValue(const nsAString&,const 
nsAString&)
nsHTMLDocument::AttributeChanged(nsIContent*,int,nsIAtom*,int,nsChangeHint)
nsDocument::AttributeChanged(nsIContent*,int,nsIAtom*,int,nsChangeHint)
PresShell::AttributeChanged(nsIDocument*,nsIContent*,int,nsIAtom*,int,nsChangeHi
nt)
StyleSetImpl::AttributeChanged(nsIPresContext*,nsIContent*,int,nsIAtom*,int,nsCh
angeHint)
nsCSSFrameConstructor::AttributeChanged(nsIPresContext*,nsIContent*,int,nsIAtom*
,int,nsChangeHint)
nsCSSFrameConstructor::RecreateFramesForContent(nsIPresContext*,nsIContent*,int,
nsIStyleRule*,nsIStyleContext*)
nsCSSFrameConstructor::ContentRemoved(nsIPresContext*,nsIContent*,nsIContent*,in
t,int)
FrameManager::RemoveFrame(nsIPresContext*,nsIPresShell&,nsIFrame*,nsIAtom*,nsIFr
ame*)
nsBlockFrame::RemoveFrame(nsIPresContext*,nsIPresShell&,nsIAtom*,nsIFrame*)
nsAbsoluteContainingBlock::RemoveFrame(nsIFrame*,nsIPresContext*,nsIPresShell&,n
sIAtom*,nsIFrame*)
nsFrameList::DestroyFrame(nsIPresContext*,nsIFrame*)
nsAreaFrame::Destroy(nsIPresContext*)
nsBlockFrame::Destroy(nsIPresContext*)
nsLineBox::DeleteLineList(nsIPresContext*,nsLineList&)
nsBlockFrame::Destroy(nsIPresContext*)
nsLineBox::DeleteLineList(nsIPresContext*,nsLineList&)
nsImageFrame::Destroy(nsIPresContext*)
nsSplittableFrame::Destroy(nsIPresContext*)
nsFrame::Destroy(nsIPresContext*)

Original comment by classi...@floodgap.com on 19 Aug 2009 at 3:52

[GoogleCodeExporter]

not 275574

Original comment by classi...@floodgap.com on 19 Aug 2009 at 3:54

[GoogleCodeExporter]

but while we were investigating, random intervening crash,

nsScriptSecurityManager::CanAccess
nsScriptSecurityManager::CheckProperlyAccessImpleme
nsScriptSecurityManager::GetPropertyPolicy
PL_DHashTableOperate

Original comment by classi...@floodgap.com on 19 Aug 2009 at 3:58

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

This is a Caps bug, turns out that ironically NoScript tickles it more (even 
though
it would have been tripped anyway). Landed an abbreviated 217967 and 300853.

Original comment by classi...@floodgap.com on 19 Aug 2009 at 4:38

[GoogleCodeExporter]

Back to the original bug. not 331883

Original comment by classi...@floodgap.com on 19 Aug 2009 at 4:40

[GoogleCodeExporter]

After some exhausting review this seems to be due to a faulty view as part of 
the
offending frame which ends up as an invalid pointer at destruction time while 
the
runtime tries to clean it up.

So far no matching patch. This could be specific to Classilla; I may have missed
something with view management somewhere. The bug is mitigated if JavaScript is 
off,
disabling the offending image rotator (it instantiates after the image rotators 
turn
on the main containers), so leaving marked High but this should not block 9.0.4 
for
now unless other sites are observed.

Original comment by classi...@floodgap.com on 19 Aug 2009 at 5:27

[GoogleCodeExporter]

This was fixed by the changes for issue 51. I knew this would affect other 
places.

Original comment by classi...@floodgap.com on 23 Aug 2009 at 3:17

• Changed state: Verified

[GoogleCodeExporter]

See issue 57 for notes on Caps.

Original comment by classi...@floodgap.com on 10 Sep 2009 at 5:41