###!!! ASSERTION: Want to fire mutation events, but it's not safe: '(aNode->IsNodeOfType(nsINode::eCONTENT) && static_cast<nsIContent*>(aNode)-> IsInNativeAnonymousSubtree()) || sScriptBlockerCount == sRemovableScriptBlockerCount', file /Users/jruderman/mozilla-central/content/base/src/nsContentUtils.cpp, line 3537 This assertion was added in bug 429175.

This has just happened on a leaktest machine: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1272995035.1272999835.5986.gz

Jonas says he'll investigate here, not sure exactly what the problem is here yet.

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1273183199.1273186957.13138.gz Linux x86-64 mozilla-central leak test build on 2010/05/06 14:59:59 (w00t, another OS heard from!)

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1273186644.1273187244.17053.gz OS X 10.6.2 mozilla-central leak test build on 2010/05/06 15:57:24

Jonas, any update here?

Jonas, progress?

I should be able to do this by next wednesday (6/2)

This seems to work. I'm not really sure who to ask for review. Blake, do you feel comfortable with this? I'm particularly wondering if it's important that we clear the status as early as we do.

(In reply to comment #28) > *** Bug 563643 has been marked as a duplicate of this bug. *** Ftr, this is not random-orange on SeaMonkey, but perma-orange.

Comment on attachment 448137 [details] [diff] [review] Patch to fix There are two ways that I could see this patch causing problems: * A new page getting the status of the previous page: - This is impossible because in order to steal the status, the new page would have to run script, which means that all script blockers must have been removed, which means that we must have cleared the status already. * An old status appearing on a new page. - In order for the new page to paint, we must have returned to the event loop, which means we must have removed all script blockers, thus clearing the status and default status. So this looks good to me.

http://hg.mozilla.org/mozilla-central/rev/209cc2fb7608 Checked in. I don't think we need to take this on branches as I don't think there is an actual security problem here. I.e. the assertion is due to chrome code modifying a chrome document.

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1277176957.1277180448.17447.gz Sort of suspect, since it's while IndexedDB is breaking the tree, so I'm not reopening.

This also is still permanently happening for SeaMonkey on every Mac leak test build, see e.g.: http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1277721548.1277725056.2473.gz&fulltext=1

Robert: Can you provide a stack (ideally including a JS-stack, though that might not be needed) that shows when the assertion is firing?

(In reply to comment #36) > Robert: Can you provide a stack (ideally including a JS-stack, though that > might not be needed) that shows when the assertion is firing? The most I think I can get out is what is being printed in the log linked above, here's the part of that which lists the stack for this assertion.

None of the symbols in that stack make any sense. Do you perhaps need to run it through some stack-fixup script?

(In reply to comment #38) > None of the symbols in that stack make any sense. Do you perhaps need to run it > through some stack-fixup script? No idea, that's what leaktest.py spits out, or more explicitly "python leaktest.py -- -CreateProfile default" is what we run and what spits out this stack automatically.

Leaktest can't use the new stack fixer (fix_stack_using_bpsyms) because leaktest.py doesn't take or pass on a symbol directory (bug 549897). This probably also means it can't show stacks for crashes. automation.py would normally fall back to using one of the old stack fixers, but I disabled the Mac one in bug 569981 due to it being broken on 64-bit (see bug 550335, which depends on bug 570286), being slow, and only working on Bd and not unit tests. Should we reopen bug 563643 or file a new bug for the Seamonkey issue?

(In reply to comment #41) > Created an attachment (id=454629) [details] > fixed stack: SeaMonkey Mac leak test build Referred to that in bug 563643 - thanks a lot for this, Jesse!