See testcase, which crashes directly or after a few reloads. http://crash-stats.mozilla.com/report/index/40379c3d-901b-11dd-8b4f-001cc4e2bf68?p=1 0 xul.dll nsINode::AppendChildTo obj-firefox/dist/include/content/nsINode.h:334 1 xul.dll HTMLContentSink::ProcessLINKTag content/html/document/src/nsHTMLContentSink.cpp:2940 2 xul.dll xul.dll@0x30c801 I guess this is a regression from bug 364315.
This is a really bad crash that's a regression from bug 457806. I'm working on a fix; however, given the complexity of the code we're touching, I recommend backing out bug 457806 for beta.
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P1
Target Milestone: --- → mozilla1.9.1b1
Blake and I talked about this and I think our best approach here is to fix this bug with a minimal patch (a subset of Blake's fix in this bug) and do it for beta1. If we don't, we'll need to fix this later in the release that means less testing, or back out the patch that caused this and probably live with the hang in that bug for this whole release. Therefore I think we should take Blake's upcoming patch that is very isolated only to the source element for beta1 and leave things as such for 1.9.1 final.
I included a mochitest too.
I checked this in on Friday but forgot to note it in the bug: http://hg.mozilla.org/mozilla-central/rev/0c1ec80708a1
Shouldn't this be marked fixed then?
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
verified fixed using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081013 Minefield/3.1b2pre. I verified using the testcase in Comment 0.
Status: RESOLVED → VERIFIED
Crash Signature: [@ nsINode::AppendChildTo]
You need to log in before you can comment on or make changes to this bug.