Closed Bug 143862 Opened 23 years ago Closed 22 years ago

document.write crashes on some pages

Categories

(Core :: Layout, defect, P2)

x86
Windows 98
defect

Tracking

()

RESOLVED FIXED
mozilla1.2alpha

People

(Reporter: jruderman, Assigned: dbaron)

Details

(Keywords: crash, testcase, Whiteboard: [patch])

Attachments

(3 files, 3 obsolete files)

A page with html,body { overflow: hidden; } crashes when I replace the page using document.write(). I don't think overflow:hidden is the only way to trigger the crash, since I was seeing a crash with the same page before I added overflow:hidden. I encountered this bug while writing http://www.squarefree.com/htmledit/, but I was able to work around the crash easily.
Attached file testcase - crashes Mozilla (obsolete) (deleted) —
Confirmed 2002050906-1.0 branch. Oh dear.
er, sorry, the talkback is TB6197720K .
Confirming with RC 2 on WinXP. Talkback-ID: TB6198550K
Here's the top o' the stack for that incident: FrameManager::ReResolveStyleContext [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1730] FrameManager::ReResolveStyleContext [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1901] FrameManager::ReResolveStyleContext [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1901] FrameManager::ReResolveStyleContext [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1901] FrameManager::ComputeStyleChangeFor [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1945] PresShell::ReconstructStyleData [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5395] PresShell::StyleSheetAdded [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5419] nsDocument::AddStyleSheet [d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp, line 1349] I've tinkered around in this code, I'll take a look.
Assignee: attinasi → waterson
Keywords: crash
Priority: -- → P2
Target Milestone: --- → mozilla1.0.1
Target Milestone: mozilla1.0.1 → mozilla1.1beta
Target Milestone: mozilla1.1beta → Future
Status: NEW → ASSIGNED
this could be a double bug. without the <style> I could still reproduce the crash. If I add document.open(); before document.write(); the page loads fine. If I add <style> back, the browser will crash whether there is document.open() or not.
The fact that we're doing a ReResolve seems to me to be a bug: #15 0x42305b0f in FrameManager::ComputeStyleChangeFor (this=0x8bd2560, aPresContext=0x84f32a8, aFrame=0x8a60f64, aAttrNameSpaceID=-1, aAttribute=0x0, aChangeList=@0xbfffd0dc, aMinChange=0, aTopLevelChange=@0xbfffd0d8) at /home/dbaron/builds/trunk/mozilla/layout/html/base/src/nsFrameManager.cpp:1903 #16 0x423640a6 in PresShell::ReconstructStyleData (this=0x88ac818, aRebuildRuleTree=0) at /home/dbaron/builds/trunk/mozilla/layout/html/base/src/nsPresShell.cpp:5526 #17 0x42364214 in PresShell::StyleSheetAdded (this=0x88ac818, aDocument=0x89a9bb0, aStyleSheet=0x85c7170) at /home/dbaron/builds/trunk/mozilla/layout/html/base/src/nsPresShell.cpp:5551 #18 0x4183d95a in nsDocument::AddStyleSheet (this=0x89a9bb0, aSheet=0x85c7170, aFlags=0) at /home/dbaron/builds/trunk/mozilla/content/base/src/nsDocument.cpp:1480 #19 0x41694610 in nsHTMLDocument::BaseResetToURI (this=0x89a9bb0, aURL=0x89a9710) at /home/dbaron/builds/trunk/mozilla/content/html/document/src/nsHTMLDocument.cpp:470 #20 0x416942d6 in nsHTMLDocument::ResetToURI (this=0x89a9bb0, aURI=0x89a9710, aLoadGroup=0x859b210) at /home/dbaron/builds/trunk/mozilla/content/html/document/src/nsHTMLDocument.cpp:427 #21 0x4183b4d9 in nsDocument::Reset (this=0x89a9bb0, aChannel=0x866aa98, aLoadGroup=0x859b210) at /home/dbaron/builds/trunk/mozilla/content/base/src/nsDocument.cpp:706 #22 0x4169c34b in nsHTMLDocument::OpenCommon (this=0x89a9bb0, aSourceURL=0x89a9710) at /home/dbaron/builds/trunk/mozilla/content/html/document/src/nsHTMLDocument.cpp:2412 #23 0x4169cca9 in nsHTMLDocument::Open (this=0x89a9bb0, aReturn=0xbfffd4ec) at /home/dbaron/builds/trunk/mozilla/content/html/document/src/nsHTMLDocument.cpp:2518 #24 0x4169ca75 in nsHTMLDocument::Open (this=0x89a9bb0) at /home/dbaron/builds/trunk/mozilla/content/html/document/src/nsHTMLDocument.cpp:2487 #25 0x4169cfa6 in nsHTMLDocument::WriteCommon (this=0x89a9bb0, aText=@0xbfffd6bc, aNewlineTerminate=0) at /home/dbaron/builds/trunk/mozilla/content/html/document/src/nsHTMLDocument.cpp:2587 #26 0x4169dd45 in nsHTMLDocument::ScriptWriteCommon (this=0x89a9bb0, aNewlineTerminate=0) at /home/dbaron/builds/trunk/mozilla/content/html/document/src/nsHTMLDocument.cpp:2707 #27 0x4169dfd5 in nsHTMLDocument::Write (this=0x89a9bb0) at /home/dbaron/builds/trunk/mozilla/content/html/document/src/nsHTMLDocument.cpp:2733 #28 0x4025fb4c in XPTC_InvokeByIndex (that=0x89a9d5c, methodIndex=19, paramCount=0, params=0xbfffd960) at /home/dbaron/builds/trunk/mozilla/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_unixish_x86.cpp:130 That said, we also shouldn't crash when doing the ReResolve.
(The bug above would be that this code should have set up the stylesheets before creating any frames.)
Attached file minimal testcase (deleted) —
This seems to depend on HTML having overflow:hidden, not BODY.
Attachment #83252 - Attachment is obsolete: true
So, what seems to be happening is that we're getting two ReResolves. The first is happening here: #0 FrameManager::ComputeStyleChangeFor (this=0x86cde78, aPresContext=0x8665cc0, aFrame=0x88798cc, aAttrNameSpaceID=-1, aAttribute=0x0, aChangeList=@0xbfffd030, aMinChange=0, aTopLevelChange=@0xbfffd02c) at /home/dbaron/builds/trunk/mozilla/layout/html/base/src/nsFrameManager.cpp:1887 #1 0x423260a6 in PresShell::ReconstructStyleData (this=0x80e84e0, aRebuildRuleTree=1) at /home/dbaron/builds/trunk/mozilla/layout/html/base/src/nsPresShell.cpp:5526 #2 0x42326238 in PresShell::StyleSheetRemoved (this=0x80e84e0, aDocument=0x86bf430, aStyleSheet=0x8878f88) at /home/dbaron/builds/trunk/mozilla/layout/html/base/src/nsPresShell.cpp:5560 #3 0x4183dc12 in nsDocument::RemoveStyleSheet (this=0x86bf430, aSheet=0x8878f88) at /home/dbaron/builds/trunk/mozilla/content/base/src/nsDocument.cpp:1521 #4 0x418f84f8 in nsStyleLinkElement::UpdateStyleSheet (this=0x86ceecc, aOldDocument=0x86bf430, aDocIndex=-1) at /home/dbaron/builds/trunk/mozilla/content/base/src/nsStyleLinkElement.cpp:181 #5 0x4165b997 in nsHTMLStyleElement::SetDocument (this=0x86ceea0, aDocument=0x0, aDeep=1, aCompileEventHandlers=1) at /home/dbaron/builds/trunk/mozilla/content/html/content/src/nsHTMLStyleElement.cpp:123 #6 0x4188dc61 in nsGenericElement::SetDocumentInChildrenOf ( aContent=0x86ac300, aDocument=0x0, aCompileEventHandlers=1) at /home/dbaron/builds/trunk/mozilla/content/base/src/nsGenericElement.cpp:1574 #7 0x4188e18b in nsGenericElement::SetDocument (this=0x86ac300, aDocument=0x0, aDeep=1, aCompileEventHandlers=1) at /home/dbaron/builds/trunk/mozilla/content/base/src/nsGenericElement.cpp:1639 #8 0x415c6765 in nsGenericHTMLElement::SetDocument (this=0x86ac300, aDocument=0x0, aDeep=1, aCompileEventHandlers=1) at /home/dbaron/builds/trunk/mozilla/content/html/content/src/nsGenericHTMLElement.cpp:1278 #9 0x415d090c in nsGenericHTMLContainerElement::RemoveChildAt ( this=0x86c9b28, aIndex=0, aNotify=1) at /home/dbaron/builds/trunk/mozilla/content/html/content/src/nsGenericHTMLElement.cpp:4137 #10 0x4169c119 in nsHTMLDocument::OpenCommon (this=0x86bf430, aSourceURL=0x8656630) at /home/dbaron/builds/trunk/mozilla/content/html/document/src/nsHTMLDocument.cpp:2380 #11 0x4169cca9 in nsHTMLDocument::Open (this=0x86bf430, aReturn=0xbfffda30) at /home/dbaron/builds/trunk/mozilla/content/html/document/src/nsHTMLDocument.cpp:2518 #12 0x412fe340 in nsHTMLDocumentSH::DocumentOpen (cx=0x85c50d8, obj=0x85a8200, argc=0, argv=0x8869e04, rval=0xbfffdbc0) at /home/dbaron/builds/trunk/mozilla/dom/src/base/nsDOMClassInfo.cpp:4657 And the second one is happening here: #0 FrameManager::ComputeStyleChangeFor (this=0x86cde78, aPresContext=0x8665cc0, aFrame=0x88798cc, aAttrNameSpaceID=-1, aAttribute=0x0, aChangeList=@0xbfffd620, aMinChange=0, aTopLevelChange=@0xbfffd61c) at /home/dbaron/builds/trunk/mozilla/layout/html/base/src/nsFrameManager.cpp:1887 #1 0x423260a6 in PresShell::ReconstructStyleData (this=0x80e84e0, aRebuildRuleTree=0) at /home/dbaron/builds/trunk/mozilla/layout/html/base/src/nsPresShell.cpp:5526 #2 0x42326214 in PresShell::StyleSheetAdded (this=0x80e84e0, aDocument=0x86bf430, aStyleSheet=0x86c9740) at /home/dbaron/builds/trunk/mozilla/layout/html/base/src/nsPresShell.cpp:5551 #3 0x4183d95a in nsDocument::AddStyleSheet (this=0x86bf430, aSheet=0x86c9740, aFlags=0) at /home/dbaron/builds/trunk/mozilla/content/base/src/nsDocument.cpp:1480 #4 0x41694610 in nsHTMLDocument::BaseResetToURI (this=0x86bf430, aURL=0x8656630) at /home/dbaron/builds/trunk/mozilla/content/html/document/src/nsHTMLDocument.cpp:470 #5 0x416942d6 in nsHTMLDocument::ResetToURI (this=0x86bf430, aURI=0x8656630, aLoadGroup=0x85c8188) at /home/dbaron/builds/trunk/mozilla/content/html/document/src/nsHTMLDocument.cpp:427 #6 0x4183b4d9 in nsDocument::Reset (this=0x86bf430, aChannel=0x864dfa0, aLoadGroup=0x85c8188) at /home/dbaron/builds/trunk/mozilla/content/base/src/nsDocument.cpp:706 #7 0x4169c34b in nsHTMLDocument::OpenCommon (this=0x86bf430, aSourceURL=0x8656630) at /home/dbaron/builds/trunk/mozilla/content/html/document/src/nsHTMLDocument.cpp:2412 #8 0x4169cca9 in nsHTMLDocument::Open (this=0x86bf430, aReturn=0xbfffda30) at /home/dbaron/builds/trunk/mozilla/content/html/document/src/nsHTMLDocument.cpp:2518 #9 0x412fe340 in nsHTMLDocumentSH::DocumentOpen (cx=0x85c50d8, obj=0x85a8200, argc=0, argv=0x8869e04, rval=0xbfffdbc0) at /home/dbaron/builds/trunk/mozilla/dom/src/base/nsDOMClassInfo.cpp:4657 We crash within this second ReResolve, which suggests that the first ReResolve wasn't handled correctly in some way -- either the change list was wrong, or, more likely, the change list from the first ReResolve wasn't processed fully and the frames that were supposed to be reconstructed were not, leaving them pointing to old style contexts that pointed into the old rule tree. (Note that the first of the two ReResolves did a rule tree reconstruct.) We crash because we're pointing into the old rule tree (at least in my tree, where I have 0xdd marking of FrameArena deletion).
Attached file alternative testcase (deleted) —
Attached patch patch (obsolete) (deleted) — Splinter Review
This fixes the problem -- RecreateFramesForContent didn't handle the root content node correctly -- it just blindly null-checked the parent. If it's given the root, it should just call ReconstructDocElementHierarchy to recreate all the frames.
Taking bug. (And, BTW, I'm less convinced that what the document.open code is doing is a bug -- since it's reusing the same document object. It would be nice if we could batch changes, but that's not a bug per se.)
Assignee: waterson → dbaron
Status: ASSIGNED → NEW
Target Milestone: Future → mozilla1.1beta
To add to comment 12 -- what happens in the document.open() or document.write() case is that we remove all the old content for the document, including the stylesheet. This removes the overflow property declaration that matches the root node, so we generate a framechange hint for the root node. Then ReResolve stops when it hits the framechange hint since it assumes that the frames will be destroyed so there's no problem if they point to stale style contexts. However, RecreateFramesForContent fails to destroy the frames (see comment 12), so we crash when we try to access style contexts that point to deleted rule nodes.
Comment on attachment 89824 [details] [diff] [review] patch sr=waterson
Attachment #89824 - Flags: superreview+
Comment on attachment 89824 [details] [diff] [review] patch r=bzbarsky
Attachment #89824 - Flags: review+
So it turns out this patch causes content to be doubled intermittently on some pages (my.netscape.com, bugzilla bug pages). This is happening because we're getting a RecreateFramesForContent call for a content node that is an "option" element. We're getting a ContentStatesChanged notification with the stack: #1 0x425a30db in nsCSSFrameConstructor::RecreateFramesForContent ( this=0x87fbb90, aPresContext=0x8849590, aContent=0x8800190, aInlineStyle=0, aInlineStyleRule=0x0, aStyleContext=0x0) at /home/dbaron/builds/trunk/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp:12244 #2 0x4259d14d in nsCSSFrameConstructor::ContentStatesChanged (this=0x87fbb90, aPresContext=0x8849590, aContent1=0x8800190, aContent2=0x0, aStateMask=16) at /home/dbaron/builds/trunk/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp:10537 #3 0x418dc66f in StyleSetImpl::ContentStatesChanged (this=0x88a63e0, aPresContext=0x8849590, aContent1=0x8800190, aContent2=0x0, aStateMask=16) at /home/dbaron/builds/trunk/mozilla/content/base/src/nsStyleSet.cpp:1574 #4 0x4250a1b6 in PresShell::ContentStatesChanged (this=0x8657e10, aDocument=0x858f6f8, aContent1=0x8800190, aContent2=0x0, aStateMask=16) at /home/dbaron/builds/trunk/mozilla/layout/html/base/src/nsPresShell.cpp:5272 #5 0x4183fd18 in nsDocument::ContentStatesChanged (this=0x858f6f8, aContent1=0x8800190, aContent2=0x0, aStateMask=16) at /home/dbaron/builds/trunk/mozilla/content/base/src/nsDocument.cpp:2050 #6 0x4163da6b in nsHTMLOptionElement::SetSelectedInternal (this=0x8800190, aValue=1, aNotify=1) at /home/dbaron/builds/trunk/mozilla/content/html/content/src/nsHTMLOptionElement.cpp:272 #7 0x4164d479 in nsHTMLSelectElement::OnOptionSelected (this=0x87f8850, aSelectFrame=0x0, aPresContext=0x0, aIndex=4, aSelected=1, aNotify=1) at /home/dbaron/builds/trunk/mozilla/content/html/content/src/nsHTMLSelectElement.cpp:1069 #8 0x4164b4e5 in nsHTMLSelectElement::InsertOptionsIntoList (this=0x87f8850, aOptions=0x8800190, aListIndex=4, aLevel=0) at /home/dbaron/builds/trunk/mozilla/content/html/content/src/nsHTMLSelectElement.cpp:469 #9 0x4164bd29 in nsHTMLSelectElement::WillAddOptions (this=0x87f8850, aOptions=0x8800190, aParent=0x87f8850, aContentIndex=4) at /home/dbaron/builds/trunk/mozilla/content/html/content/src/nsHTMLSelectElement.cpp:684 #10 0x4164b14b in nsHTMLSelectElement::AppendChildTo (this=0x87f8850, aKid=0x8800190, aNotify=0, aDeepSetDocument=0) at /home/dbaron/builds/trunk/mozilla/content/html/content/src/nsHTMLSelectElement.cpp:374 #11 0x4167d136 in SinkContext::CloseContainer (this=0x8473308, aNode=@0x87cf220) at /home/dbaron/builds/trunk/mozilla/content/html/document/src/nsHTMLContentSink.cpp:1496 #12 0x41682de8 in HTMLContentSink::CloseContainer (this=0x8656730, aNode=@0x87cf220) at /home/dbaron/builds/trunk/mozilla/content/html/document/src/nsHTMLContentSink.cpp:3237 ...
Attached patch patch, v. 2.0 (obsolete) (deleted) — Splinter Review
The additional change in nsHTMLSelectElement.cpp is the change that prevents the problem in comment 17. The change in nsHTMLOptionElement.cpp is a fix for a slight performance problem that bz and I noticed when looking over a profile sometime last week.
Attachment #89824 - Attachment is obsolete: true
Comment on attachment 90125 [details] [diff] [review] patch, v. 2.0 sr=jst
Attachment #90125 - Flags: superreview+
Comment on attachment 90125 [details] [diff] [review] patch, v. 2.0 r=jkeiser with a comment in nsHTMLOptionElement explaining that this always happens before frame construction
Attachment #90125 - Flags: review+
Fix checked in 2002-07-09 19:24 PDT.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
regression bug 156719 - Crash on File Bookmark with multiple tabs open ...?
reopening bug since checkin on 7.9.2002 (changes in |RecreateFramesForContent|) is causing new topcrsh, rank 13, on windows platform. cc-ing asa, chofmann, and talkback team. call stack and user comments below: nsQueryInterface::operator (53 crashes) BBID range: 8082645 - 8200525 Min/Max Seconds since last crash: 0 - 82346 Min/Max Runtime: 9 - 82346 Crash data range: 2002-07-07 to 2002-07-10 Build ID range: 2002070704 to 2002071008 Stack Trace: nsQueryInterface::operator() [c:/builds/seamonkey/mozilla/xpcom/glue/nsCOMPtr.cpp line 52] nsCOMPtr_base::assign_from_helper [c:/builds/seamonkey/mozilla/xpcom/glue/nsCOMPtr.cpp line 81] nsCSSFrameConstructor::ConstructXULFrame [c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp line 5859] nsCSSFrameConstructor::ConstructFrameInternal [c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp line 7384] nsCSSFrameConstructor::ConstructFrame [c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp line 7259] nsCSSFrameConstructor::CreateAnonymousFrames [c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp line 5230] nsCSSFrameConstructor::CreateAnonymousFrames [c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp line 5168] nsCSSFrameConstructor::ConstructDocElementFrame [c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp line 3487] nsCSSFrameConstructor::ReconstructDocElementHierarchy [c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp line 7526] nsCSSFrameConstructor::RecreateFramesForContent [c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp line 12237] nsCSSFrameConstructor::ContentStatesChanged [c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp line 10532] StyleSetImpl::ContentStatesChanged [c:/builds/seamonkey/mozilla/content/base/src/nsStyleSet.cpp line 1575] PresShell::ContentStatesChanged [c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp line 5275] nsXULDocument::ContentStatesChanged [c:/builds/seamonkey/mozilla/content/xul/document/src/nsXULDocument.cpp line 2064] nsEventStateManager::SetContentState [c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp line 3778] nsEventStateManager::GenerateMouseEnterExit [c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp line 2377] nsEventStateManager::PreHandleEvent [c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp line 393] PresShell::HandleEventInternal [c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp line 6187] PresShell::HandleEvent [c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp line 6115] nsViewManager::HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp line 2105] nsView::HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsView.cpp line 306] nsViewManager::DispatchEvent [c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp line 1916] HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsView.cpp line 83] nsWindow::DispatchEvent [c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp line 1038] nsWindow::DispatchWindowEvent [c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp line 1055] nsWindow::DispatchMouseEvent [c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp line 5097] ChildWindow::DispatchMouseEvent [c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp line 5352] nsWindow::ProcessMessage [c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp line 3814] nsWindow::WindowProc [c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp line 1304] USER32.dll + 0x3a5f (0x77d43a5f) USER32.dll + 0x3b2e (0x77d43b2e) USER32.dll + 0x3d6a (0x77d43d6a) USER32.dll + 0x41fd (0x77d441fd) nsAppShellService::Run [c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsAppShellService.cpp line 452] main1 [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp line 1472] main [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp line 1808] WinMain [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp line 1826] WinMainCRTStartup() kernel32.dll + 0x1eb69 (0x77e7eb69) nsQueryInterface::operator() [c:/builds/seamonkey/mozilla/xpcom/glue/nsCOMPtr.cpp line 52] nsCOMPtr_base::assign_from_helper [c:/builds/seamonkey/mozilla/xpcom/glue/nsCOMPtr.cpp line 81] nsCSSFrameConstructor::ConstructXULFrame [c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp line 5859] nsCSSFrameConstructor::ConstructFrameInternal [c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp line 7384] nsCSSFrameConstructor::ConstructFrame [c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp line 7259] nsCSSFrameConstructor::CreateAnonymousFrames [c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp line 5230] nsCSSFrameConstructor::CreateAnonymousFrames [c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp line 5168] nsCSSFrameConstructor::ConstructDocElementFrame [c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp line 3487] nsCSSFrameConstructor::ReconstructDocElementHierarchy [c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp line 7526] nsCSSFrameConstructor::RecreateFramesForContent [c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp line 12237] nsCSSFrameConstructor::ContentStatesChanged [c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp line 10532] StyleSetImpl::ContentStatesChanged [c:/builds/seamonkey/mozilla/content/base/src/nsStyleSet.cpp line 1575] PresShell::ContentStatesChanged [c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp line 5275] nsXULDocument::ContentStatesChanged [c:/builds/seamonkey/mozilla/content/xul/document/src/nsXULDocument.cpp line 2064] nsEventStateManager::SetContentState [c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp line 3778] nsEventStateManager::GenerateMouseEnterExit [c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp line 2377] nsEventStateManager::PreHandleEvent [c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp line 393] PresShell::HandleEventInternal [c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp line 6187] PresShell::HandleEvent [c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp line 6115] nsViewManager::HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp line 2105] nsView::HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsView.cpp line 306] nsViewManager::DispatchEvent [c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp line 1916] HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsView.cpp line 83] nsWindow::DispatchEvent [c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp line 1038] nsWindow::DispatchWindowEvent [c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp line 1055] nsWindow::DispatchMouseEvent [c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp line 5097] ChildWindow::DispatchMouseEvent [c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp line 5352] nsWindow::ProcessMessage [c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp line 3814] nsWindow::WindowProc [c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp line 1304] USER32.dll + 0x3a5f (0x77d43a5f) USER32.dll + 0x3b2e (0x77d43b2e) USER32.dll + 0x3d6a (0x77d43d6a) USER32.dll + 0x41fd (0x77d441fd) nsAppShellService::Run [c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsAppShellService.cpp line 452] main1 [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp line 1472] main [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp line 1808] WinMain [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp line 1826] WinMainCRTStartup() kernel32.dll + 0x1eb69 (0x77e7eb69) Source File : c:/builds/seamonkey/mozilla/xpcom/glue/nsCOMPtr.cpp line : 52 8200525 OS: Windows NT 5.1 build 2600 8200227 OS: Windows NT 5.0 build 2195 Comments: create two tabs pointing to any two pages; do Bookmarks->Create Bookmark for this Group; crash; new in 07/10 trunk builds (not in 07/09) Email: jrgm@netscape.com 8200141 OS: Windows NT 5.0 build 2195 URL: http://momonga.t.u-tokyo.ac.jp/~ooura/fftman/ftmndl.html Email: takeyori@cs.fujitsu.co.jp 8199723 OS: Windows NT 5.0 build 2195 8199335 OS: Windows NT 5.0 build 2195 8198985 OS: Windows NT 5.0 build 2195 8198761 OS: Windows NT 5.1 build 2600 Comments: 3rd occurrence in a row of crashing when trying to come out of full screen mode. Email: nbas@canada.com 8198729 OS: Windows NT 5.1 build 2600 Comments: 2nd occurrence in a row of this incident. Had clicked on bar to go from full screen mode to showing the address bar. Email: nbas@canada.com 8198720 OS: Windows 98 4.10 build 67766446 8198700 OS: Windows NT 5.1 build 2600 Comments: blank page was opening the address bar as I had it compressed(full screen mode) Email: nbas@canada.com 8197871 OS: Windows NT 5.0 build 2195 Comments: Had just done a "File Bookmark..." from the bookmarks menu after navigating to this page. (I can reconstruct the history trail if you'd like.)-Robert URL: http://www.allmyfaqs.com/faq.pl?AnySizeDesign Email: Robert Lentz 8197499 OS: Windows NT 5.0 build 2195 8197422 OS: Windows 98 4.10 build 67766222 Comments: 3 tabs open mail. I tried to "file" a bookmark moz crashed Email: treebeard@treebeard.net 8197065 OS: Windows 98 4.10 build 67766446 Email: kchen@mit.edu 8196485 OS: Windows NT 4.0 build 1381 Comments: hitting back button 8196109 OS: Windows 98 4.10 build 67766446 8196096 OS: Windows 98 4.10 build 67766446 8196076 OS: Windows 98 4.10 build 67766446 8195978 OS: Windows NT 5.0 build 2195 8195270 OS: Windows 98 4.10 build 67766446 Email: kchen@mit.edu 8194669 OS: Windows 98 4.10 build 67766446 Email: kchen@mit.edu 8193749 OS: Windows NT 5.0 build 2195 Comments: Clicked on the File Bookmark button and browser crashed Email: david@marshy.com 8192662 OS: Windows NT 4.0 build 1381 URL: http://mec2.tm.chiba-u.ac.jp/~hirata/mss/ Email: takeyori@cs.fujitsu.co.jp 8192126 OS: Windows 98 4.10 build 67766446 8190491 OS: Windows NT 5.0 build 2195 Comments: starting up URL: www.kmsp.tv 8190481 OS: Windows NT 5.0 build 2195 URL: www.kmsp.tv 8189975 OS: Windows 98 4.10 build 67766222 8189952 OS: Windows NT 5.1 build 2600 8189947 OS: Windows NT 5.1 build 2600 8189927 OS: Windows NT 5.1 build 2600 8189086 OS: Windows NT 5.1 build 2600 8188707 OS: Windows NT 5.0 build 2195 8183643 OS: Windows NT 5.1 build 2600 8182902 OS: Windows NT 5.0 build 2195 Comments: I tried to "File Bookmark..." ona tab in the browser with the above URL URL: http://www.ncp.de/deutsch/security/securityfeatures/index.html Email: cmack@spcie.de 8182870 OS: Windows NT 5.0 build 2195 Comments: tabs open. File bookmark. 8182363 OS: Windows NT 5.0 build 2195 Comments: Attempted to file bookmark URL: http://www.wise.com/displayArticle.asp?articleno=1531 8182299 OS: Windows NT 5.0 build 2195 Comments: Went to File bookmark URL: http://www.wise.com/displayArticle.asp?articleno=1531 8182226 OS: Windows NT 5.0 build 2195 8181802 OS: Windows NT 5.0 build 2195 8181492 OS: Windows NT 5.0 build 2195 Comments: Moving an icon on my Personal Tool Bar. Email: mikeydtn@charter.net 8180001 OS: Windows NT 5.0 build 2195 8178034 OS: Windows NT 5.1 build 2600 Comments: viewing a JPeG attachment in a yahoo group message URL: groups.yahoo.com/... Email: estokes@CritPath.org 8177964 OS: Windows NT 5.0 build 2195 8175155 OS: Windows 98 4.10 build 67766446 8175138 OS: Windows 98 4.10 build 67766446 8175107 OS: Windows 98 4.10 build 67766446 8175097 OS: Windows 98 4.10 build 67766446 8174590 OS: Windows NT 5.1 build 2600 8160715 OS: Windows NT 5.1 build 2600 8143493 OS: Windows NT 5.0 build 2195 Comments: Went to prefs changed minimum font size -> Crash Email: greer@netscape.com 8123440 OS: Windows NT 5.1 build 2600 Email: k3vin_d@hotmail.com 8098138 OS: Windows NT 5.1 build 2600 8082645 OS: Windows 98 4.10 build 67766446 Comments: pref-toolbar => [_] images URL: adobe.com
Severity: critical → blocker
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
*This* bug is fixed. The new crash is bug 156719 (which is actually the same problem as bug 136513), and I've had a fix since yesterday that I'm working on getting checked in. Is it now standard talkback procedure to morph bugs whenever a checkin causes a crash? We should *mention* the regression on the bug, but not reopen unless the change needs to be backed out.
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
(And by mention, I mean put a pointer to the bug that has the details, not paste hundreds of lines of details that aren't relevant to the bug. Our bugs serve as a record of what's been done, and why, and adding hundreds of lines of talkback data that belongs elsewhere makes them significantly more confusing.)
for 1.1beta this, along with bug 156719 was backed out because they were causing bug 157322
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Keywords: testcase
Whiteboard: [patch]
Target Milestone: mozilla1.1beta → mozilla1.2alpha
Attached patch patch, v. 2.1 (deleted) — Splinter Review
This is slightly revised -- the only change from what was checked in before is that the null check of |doc| in nsCSSFrameConstructor.cpp is now done in release builds, and we don't reconstruct if the content isn't in the document, since doing a reconstruct on something like navigator.xul can have bad consequences. See bug 157322 for more.
Attachment #90125 - Attachment is obsolete: true
Fix checked in, 2002-08-19 11:35 PDT.
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
Crashtests checked in.
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: