[FIX] M17rc2 - Removing nodes with line wraps can cause immediate crash of Mozilla - Trunk [@ 0x00000000 - nsCSSFrameConstructor::FindFrameWithContent ][@ nsCSSFrameConstructor::FindFrameWithContent ] (crash on file input)

VERIFIED FIXED

Status

()

Core
Layout: Form Controls
--
critical
VERIFIED FIXED
15 years ago
7 years ago

People

(Reporter: Kelley Reynolds, Assigned: Brian Ryner (not reading))

Tracking

(5 keywords)

Trunk
x86
All
crash, fixed1.7, regression, testcase, topcrash
Points:
---
Bug Flags:
blocking1.7 +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed-aviary1.0, crash signature, URL)

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4a) Gecko/20030418
Build Identifier: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4a) Gecko/20030418

Click on 'attach files' to add nodes, then click on 'delete' to remove nodes.
This works as long as 'delete' doesn't wrap around to the next line. If one
makes the browser window small enough so that the 'delete' word wraps around
underneath the 'file' form element, it will crash Mozilla 1.3 and 1.4a on
windows, freebsd, and linux.

Reproducible: Always

Steps to Reproduce:
1.Click on attach file.
2.Resize the window so that delete is underneath the file element
3.click on delete

Actual Results:  
Mozilla crashed entirely.

Expected Results:  
Mozilla should not have disappeared. It should have behaved the same as when
delete was at the end of the line.

1.2.1 on Windows doesn't appear to have this problem.
###!!! ASSERTION: frame was not removed from primary frame map before
destruction or was readded to map after being removed:
'!PL_DHASH_ENTRY_IS_BUSY(entry) || entry->frame != aFrame', file
/home/bzbarsky/mozilla/xlib/mozilla/layout/html/base/src/nsFrameManager.cpp,
line 1050

Stack is:

#0  0xdddddddd in ?? ()
#1  0x40ee6849 in nsCSSFrameConstructor::FindPrimaryFrameFor (this=0x8506a80, 
    aPresContext=0x87cfce0, aFrameManager=0x8524930, aContent=0x8791520, 
    aFrame=0xbfffce64, aHint=0x0)
    at
/home/bzbarsky/mozilla/xlib/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp:11822
#2  0x40ff4d9d in StyleSetImpl::FindPrimaryFrameFor (this=0x86dc548, 
    aPresContext=0x87cfce0, aFrameManager=0x8524930, aContent=0x8791520, 
    aFrame=0xbfffce64, aHint=0x0)
    at /home/bzbarsky/mozilla/xlib/mozilla/content/base/src/nsStyleSet.cpp:1825
#3  0x40e33328 in FrameManager::GetPrimaryFrameFor (this=0x8524930,
aContent=0x8791520, 
    aResult=0xbfffce64)
    at
/home/bzbarsky/mozilla/xlib/mozilla/layout/html/base/src/nsFrameManager.cpp:681
#4  0x40e7cc13 in PresShell::GetPrimaryFrameFor (this=0x8506b70,
aContent=0x8791520, 
    aResult=0xbfffce64)
    at /home/bzbarsky/mozilla/xlib/mozilla/layout/html/base/src/nsPresShell.cpp:5704
#5  0x41037c05 in nsGenericHTMLElement::GetPrimaryFrameFor (aContent=0x8791520, 
    aDocument=0x8579328, aFlushContent=0)
    at
/home/bzbarsky/mozilla/xlib/mozilla/content/html/content/src/nsGenericHTMLElement.cpp:2619
#6  0x41037c3d in nsGenericHTMLElement::GetFormControlFrameFor (aContent=0x8791520, 
    aDocument=0x8579328, aFlushContent=0)
    at
/home/bzbarsky/mozilla/xlib/mozilla/content/html/content/src/nsGenericHTMLElement.cpp:2632
#7  0x4103d95d in nsGenericHTMLElement::GetFormControlFrame (this=0x8791520, 
    aFlushContent=0)
    at
/home/bzbarsky/mozilla/xlib/mozilla/content/html/content/src/nsGenericHTMLElement.h:254
#8  0x4106170d in nsHTMLInputElement::GetValue (this=0x8791520, aValue=@0xbfffcf90)
    at
/home/bzbarsky/mozilla/xlib/mozilla/content/html/content/src/nsHTMLInputElement.cpp:657
#9  0x41065df0 in nsHTMLInputElement::SaveState (this=0x8791520)
    at
/home/bzbarsky/mozilla/xlib/mozilla/content/html/content/src/nsHTMLInputElement.cpp:2493

-- this is the request for a primary frame we always get as a form control is
being removed from the doc... In particular, this tends to repopulate the
primary frame map with the about-to-be-destroyed frame...
Assignee: dom_bugs → form
Status: UNCONFIRMED → NEW
Component: DOM Core → Layout: Form Controls
Ever confirmed: true

Updated

15 years ago
Keywords: crash, testcase

Comment 2

15 years ago
Here's a recent Talkback incident:
Incident ID 19440535
Stack Signature 	0x00000000 33c05baf
Email Address 	aha@pinknet.cz
Product ID 	MozillaTrunk
Build ID 	2003042308
Trigger Time 	2003-04-23 15:14:07
Platform 	Win32
Operating System 	Windows NT 5.0 build 2195
Module 	
URL visited 	
User Comments 	B#203041
Trigger Reason 	Access violation
Source File Name 	
Trigger Line No. 	
Stack Trace 	
0x00000000
nsCSSFrameConstructor::FindFrameWithContent
[c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp,
line 11670]
nsCSSFrameConstructor::FindPrimaryFrameFor
[c:/builds/seamonkey/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp,
line 11847]
StyleSetImpl::FindPrimaryFrameFor
[c:/builds/seamonkey/mozilla/content/base/src/nsStyleSet.cpp, line 1826]
FrameManager::GetPrimaryFrameFor
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsFrameManager.cpp, line 683]
PresShell::GetPrimaryFrameFor
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 5705]
nsGenericHTMLElement::GetPrimaryFrameFor
[c:/builds/seamonkey/mozilla/content/html/content/src/nsGenericHTMLElement.cpp,
line 2630]
nsGenericHTMLElement::GetFormControlFrameFor
[c:/builds/seamonkey/mozilla/content/html/content/src/nsGenericHTMLElement.cpp,
line 2643]
nsHTMLInputElement::GetValue
[c:/builds/seamonkey/mozilla/content/html/content/src/nsHTMLInputElement.cpp,
line 659]
nsHTMLInputElement::SaveState
[c:/builds/seamonkey/mozilla/content/html/content/src/nsHTMLInputElement.cpp,
line 2497]
nsGenericHTMLLeafFormElement::SetDocument
[c:/builds/seamonkey/mozilla/content/html/content/src/nsGenericHTMLElement.cpp,
line 4278]
nsHTMLInputElement::SetDocument
[c:/builds/seamonkey/mozilla/content/html/content/src/nsHTMLInputElement.cpp,
line 1781]
nsGenericElement::SetDocumentInChildrenOf
[c:/builds/seamonkey/mozilla/content/base/src/nsGenericElement.cpp, line 1640]
nsGenericElement::SetDocument
[c:/builds/seamonkey/mozilla/content/base/src/nsGenericElement.cpp, line 1704]
nsGenericHTMLElement::SetDocument
[c:/builds/seamonkey/mozilla/content/html/content/src/nsGenericHTMLElement.cpp,
line 1340]
nsGenericHTMLContainerElement::RemoveChildAt
[c:/builds/seamonkey/mozilla/content/html/content/src/nsGenericHTMLElement.cpp,
line 3814]
nsGenericElement::doRemoveChild
[c:/builds/seamonkey/mozilla/content/base/src/nsGenericElement.cpp, line 2892]
nsHTMLTableCellElement::RemoveChild
[c:/builds/seamonkey/mozilla/content/html/content/src/nsHTMLTableCellElement.cpp,
line 63]
XPTC_InvokeByIndex
[c:/builds/seamonkey/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp,
line 102]
XPCWrappedNative::CallMethod
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2025]
XPC_WN_CallMethod
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1285]
js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 845]
js_Interpret [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 2836]
js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 861]
js_InternalInvoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 936]
JS_CallFunctionValue [c:/builds/seamonkey/mozilla/js/src/jsapi.c, line 3529]
nsJSContext::CallEventHandler
[c:/builds/seamonkey/mozilla/dom/src/base/nsJSEnvironment.cpp, line 1082]
nsJSEventListener::HandleEvent
[c:/builds/seamonkey/mozilla/dom/src/events/nsJSEventListener.cpp, line 183]
nsEventListenerManager::HandleEventSubType
[c:/builds/seamonkey/mozilla/content/events/src/nsEventListenerManager.cpp, line
1192]
nsEventListenerManager::HandleEvent
[c:/builds/seamonkey/mozilla/content/events/src/nsEventListenerManager.cpp, line
1363]
nsGenericElement::HandleDOMEvent
[c:/builds/seamonkey/mozilla/content/base/src/nsGenericElement.cpp, line 1925]
nsGenericHTMLElement::HandleDOMEventForAnchors
[c:/builds/seamonkey/mozilla/content/html/content/src/nsGenericHTMLElement.cpp,
line 1433]
nsHTMLLinkElement::HandleDOMEvent
[c:/builds/seamonkey/mozilla/content/html/content/src/nsHTMLLinkElement.cpp,
line 360]
PresShell::HandleEventInternal
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6377]
PresShell::HandleEventWithTarget
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6338]
nsEventStateManager::CheckForAndDispatchClick
[c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp, line 2911]
nsEventStateManager::PostHandleEvent
[c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp, line 1906]
PresShell::HandleEventInternal
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6414]
PresShell::HandleEvent
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6321]
nsViewManager::HandleEvent
[c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp, line 2292]
nsView::HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsView.cpp, line 308]
nsViewManager::DispatchEvent
[c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp, line 2028]
HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsView.cpp, line 82]
nsWindow::DispatchEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1057]
nsWindow::DispatchWindowEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1074]
nsWindow::DispatchMouseEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 5177]
ChildWindow::DispatchMouseEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 5432]
nsWindow::ProcessMessage
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 4021]
nsWindow::WindowProc
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1337]
USER32.dll + 0x2a244 (0x77e3a244)
USER32.dll + 0x45e5 (0x77e145e5)
USER32.dll + 0xa792 (0x77e1a792)
nsAppShellService::Run
[c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsAppShellService.cpp, line 479]
main1 [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1284]
main [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1650]
WinMain [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1672]
WinMainCRTStartup()
KERNEL32.dll + 0x2847c (0x77ea847c) 
Summary: Removing nodes with line wraps can cause immediate crash of Mozilla → Removing nodes with line wraps can cause immediate crash of Mozilla - Trunk [@ 0x00000000 - nsCSSFrameConstructor::FindFrameWithContent ]
*** Bug 204481 has been marked as a duplicate of this bug. ***
*** Bug 205415 has been marked as a duplicate of this bug. ***

Comment 5

15 years ago
*** Bug 192387 has been marked as a duplicate of this bug. ***

Comment 6

15 years ago
This is a regression from bug 152844 (credits to Andrew Schultz bug 207775).

+nsFileControlFrame::Destroy(nsIPresContext* aPresContext)
+{
+  // Toss the value into the control from the anonymous content, which is about
+  // to get lost.
+  if (mTextContent) {
+    nsCOMPtr<nsIDOMHTMLInputElement> input = do_QueryInterface(mTextContent);
+    nsAutoString value;
+    input->GetValue(value);
+
+    // Have it take the value, just like when input type=text goes away
+    nsCOMPtr<nsITextControlElement> fileInput = do_QueryInterface(mContent);
+    fileInput->TakeTextFrameValue(value);
+  }
+  return nsAreaFrame::Destroy(aPresContext);
 }


If I remove "input->GetValue(value);" it does not crash.
The crash is not on that line per se, it comes later, but this line seems to
be the culprit.
Assignee: form → jkeiser
Keywords: regression

Comment 7

15 years ago
*** Bug 207775 has been marked as a duplicate of this bug. ***

Comment 8

15 years ago
*** Bug 204481 has been marked as a duplicate of this bug. ***
This comes up every so often...  Basically, as I recall it, the GetValue calls
GetPrimaryFrameFor, which puts a pointer to the form control frame back into the
primary frame map (this code is running _after_ the frame has been removed from
the map).  Then the frame gets destroyed, and there is a stale pointer living in
the primary frame map.

Could you try manually removing the frame from the primary frame map after that
GetValue() call and seeing whether that helps the crash?
That fixed one of the bugs while others still crashed.
Instead, I found some code in nsTextControlFrame which does something similar
and that fixed all the bugs. I will attach the patch after I clean it up a bit.
Don't know who I should ask for review - Boris?
Summary: Removing nodes with line wraps can cause immediate crash of Mozilla - Trunk [@ 0x00000000 - nsCSSFrameConstructor::FindFrameWithContent ] → [FIX] Removing nodes with line wraps can cause immediate crash of Mozilla - Trunk [@ 0x00000000 - nsCSSFrameConstructor::FindFrameWithContent ]
Comment on attachment 125139 [details] [diff] [review]
Patch rev. 1

That would be me.  What is the actual root cause here?	Is PreDestroy() not
being called on the anonymous contents' frames?
Attachment #125139 - Flags: review?(jkeiser)
There was no nsFileControlFrame::PreDestroy() - the patch adds it in the same way
as in nsTextControlFrame.  I think Boris' comment 9 explains the situation.
What I'm trying to figure out is, why is it calling GetPrimaryFrameFor() at all?
 Since nsTextControlFrame has a PreDestroy, *that* should have been called,
which would have given the value to the input type=file, which would have set
mOwnsValue = PR_TRUE.  I'll debug here.  I just think there is a deeper problem
with the order we destroy things.

Comment 16

15 years ago
*** Bug 210620 has been marked as a duplicate of this bug. ***

Comment 17

15 years ago
*** Bug 210895 has been marked as a duplicate of this bug. ***

Comment 18

15 years ago
*** Bug 212019 has been marked as a duplicate of this bug. ***
*** Bug 212561 has been marked as a duplicate of this bug. ***
*** Bug 214188 has been marked as a duplicate of this bug. ***
*** Bug 214255 has been marked as a duplicate of this bug. ***
Summary: [FIX] Removing nodes with line wraps can cause immediate crash of Mozilla - Trunk [@ 0x00000000 - nsCSSFrameConstructor::FindFrameWithContent ] → [FIX] Removing nodes with line wraps can cause immediate crash of Mozilla - Trunk [@ 0x00000000 - nsCSSFrameConstructor::FindFrameWithContent ] (crash on file input)

Comment 22

15 years ago
*** Bug 218454 has been marked as a duplicate of this bug. ***
*** Bug 206839 has been marked as a duplicate of this bug. ***
*** Bug 223426 has been marked as a duplicate of this bug. ***

Comment 25

15 years ago
*** Bug 230990 has been marked as a duplicate of this bug. ***

Comment 26

15 years ago
URL is dead, updating with minimized testcase.
Perhaps we should just move removal from the primary frame map later (to where
we currently have the assertion)?  Or is there a problem that still having the
frame in the primary frame map that late would cause?

Comment 28

15 years ago
*** Bug 231008 has been marked as a duplicate of this bug. ***

Comment 29

14 years ago
*** Bug 233614 has been marked as a duplicate of this bug. ***

Comment 30

14 years ago
*** Bug 234351 has been marked as a duplicate of this bug. ***

Comment 31

14 years ago
*** Bug 227111 has been marked as a duplicate of this bug. ***

Comment 32

14 years ago
*** Bug 238977 has been marked as a duplicate of this bug. ***
*** Bug 239463 has been marked as a duplicate of this bug. ***

Comment 34

14 years ago
Created attachment 145954 [details]
backtrace

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040412
Firefox/0.8.0+

This crash is still in.

Comment 35

14 years ago
Adding M17beta to summary and topcrash keyword for tracking since this is a
topcrasher for Mozilla 1.7 Beta.
Keywords: topcrash
Summary: [FIX] Removing nodes with line wraps can cause immediate crash of Mozilla - Trunk [@ 0x00000000 - nsCSSFrameConstructor::FindFrameWithContent ] (crash on file input) → [FIX] Removing nodes with line wraps can cause immediate crash of Mozilla - M17beta Trunk [@ 0x00000000 - nsCSSFrameConstructor::FindFrameWithContent ][@ nsCSSFrameConstructor::FindFrameWithContent ] (crash on file input)

Comment 36

14 years ago
I just crashed with the testcase
(http://bugzilla.mozilla.org/attachment.cgi?id=139119&action=view) using Mozilla
1.7 RC1 on WinXP. 

Updated summary for tracking: M17beta -> M17rc1

Summary: [FIX] Removing nodes with line wraps can cause immediate crash of Mozilla - M17beta Trunk [@ 0x00000000 - nsCSSFrameConstructor::FindFrameWithContent ][@ nsCSSFrameConstructor::FindFrameWithContent ] (crash on file input) → [FIX] Removing nodes with line wraps can cause immediate crash of Mozilla - M17rc1 Trunk [@ 0x00000000 - nsCSSFrameConstructor::FindFrameWithContent ][@ nsCSSFrameConstructor::FindFrameWithContent ] (crash on file input)

Comment 37

14 years ago
*** Bug 242620 has been marked as a duplicate of this bug. ***

Comment 38

14 years ago
Created attachment 147697 [details]
click "OK" in the alert to trigger the crash

moving testcase over from dupe bug 242620

Comment 39

14 years ago
Actually, the alert is just a 'pause' immediately before the crash.  Removed the
alert from the test case and the browser will just crash.

Comment 40

14 years ago
anyone have any more thoughts on how to fix this?
Flags: blocking1.7?

Comment 41

14 years ago
I guess my crashs with recent trunk builds (not 1.7) are the same issue. See
TB40744Q, TB40732E and more. But I never noticed it before, I wonder in spite of
my heavy use. I only crash in Mail & News if I *drag* the vertical scrollbar
(not if I click the up/down arrows) of the recipients list in a message window.
Now this crash is the No. 1 topcrash of the trunk builds.

Comment 42

14 years ago
The attached patch might be bitrotted, but maybe still contains the solution or
hints towards it.
Please note that jkeiser is unlikely to do the review, so maybe someone else
should be contacted...

Comment 43

14 years ago
(In reply to comment #41)
> I only crash in Mail & News if I *drag* the vertical scrollbar
> (not if I click the up/down arrows) of the recipients list in a message window.
see bug 243189 comment 4: ... or If I use the keyboard to navigate through the
whole list (down/up).

Comment 44

14 years ago
Reassigning to default owners (which right now is nobody@mozilla.org).

Asa:  Any idea who might be able to look at this?
Assignee: john → nobody
QA Contact: desale → core.layout.form-controls
*** Bug 243858 has been marked as a duplicate of this bug. ***
dbaron, bz: either of you able to take this bug?

/be

Comment 47

14 years ago
(In reply to comment #43)
These crashes are gone with the fix for bug 243203 for me (although I always had
the stack signature nsCSSFrameConstructor::FindFrameWithContent). The testcase
here still crashes. Sorry for the unnecessary spam.

Comment 48

14 years ago
Updating summary with M17rc2 since this testcase crashes for me too with Mozilla
1.7 rc2:

Incident ID: 52751
Stack Signature	0x00000000 75613caa
Email Address	jay@mozilla.org
Product ID	Mozilla17
Build ID	2004051408
Trigger Time	2004-05-19 14:47:49.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	
URL visited	http://bugzilla.mozilla.org/attachment.cgi?id=139119&action=view
User Comments	Bug 203041
Since Last Crash	sec
Total Uptime	sec
Trigger Reason	Access violation
Source File Name	
Trigger Line No.	
Stack Trace 	
0x00000000
GetNifOrSpecialSibling
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp,
line 400]
nsCSSFrameConstructor::FindFrameWithContent
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp,
line 11022]
nsCSSFrameConstructor::FindPrimaryFrameFor
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp,
line 11088]
nsFrameManager::GetPrimaryFrameFor
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsFrameManager.cpp,
line 460]
PresShell::GetPrimaryFrameFor
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp,
line 5389]
nsGenericHTMLElement::GetPrimaryFrameFor
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/content/html/content/src/nsGenericHTMLElement.cpp,
line 2189]
nsGenericHTMLElement::GetFormControlFrameFor
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/content/html/content/src/nsGenericHTMLElement.cpp,
line 2199]
nsHTMLButtonElement::HandleDOMEvent
[d:/BUILDS/tinderbox/Mozilla1.7/WINNT_5.0_Clobber/mozilla/content/html/content/src/nsHTMLButtonElement.cpp,
line 375]
.
.
.

The stack looks a lot like bug 238906, but still not sure if they're dups.
Summary: [FIX] Removing nodes with line wraps can cause immediate crash of Mozilla - M17rc1 Trunk [@ 0x00000000 - nsCSSFrameConstructor::FindFrameWithContent ][@ nsCSSFrameConstructor::FindFrameWithContent ] (crash on file input) → [FIX] M17rc2 - Removing nodes with line wraps can cause immediate crash of Mozilla - Trunk [@ 0x00000000 - nsCSSFrameConstructor::FindFrameWithContent ][@ nsCSSFrameConstructor::FindFrameWithContent ] (crash on file input)
(Assignee)

Updated

14 years ago
Attachment #125139 - Flags: review?(john)
(Assignee)

Comment 49

14 years ago
Created attachment 148920 [details] [diff] [review]
patch updated to trunk
(Assignee)

Updated

14 years ago
Assignee: nobody → bryner
Attachment #125139 - Attachment is obsolete: true
Status: NEW → ASSIGNED
(Assignee)

Updated

14 years ago
Attachment #148920 - Flags: superreview?(roc)
Attachment #148920 - Flags: review?(bzbarsky)
Comment on attachment 148920 [details] [diff] [review]
patch updated to trunk

r+sr=bzbarsky.	The answer to comment 15 is that the textnode gets the frame
_unconditionally_ during the GetValue call, since the frame is what knows
whether it owns the value.  So we end up calling GetPrimaryFrameFor after the
frames have been removed from the primary frame map (that happens before we
start destroying them).

So this is exactly the right patch....
Attachment #148920 - Flags: superreview?(roc)
Attachment #148920 - Flags: superreview+
Attachment #148920 - Flags: review?(bzbarsky)
Attachment #148920 - Flags: review+

Updated

14 years ago
Flags: blocking1.7? → blocking1.7+
(Assignee)

Updated

14 years ago
Attachment #148920 - Flags: approval1.7?

Comment 51

14 years ago
Comment on attachment 148920 [details] [diff] [review]
patch updated to trunk

a=chofmann for 1.7
Attachment #148920 - Flags: approval1.7? → approval1.7+
(Assignee)

Comment 52

14 years ago
checked into trunk, 1.7 branch, and aviary branch.
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Keywords: fixed1.7
Resolution: --- → FIXED

Updated

14 years ago
Whiteboard: fixed-aviary1.0

Comment 53

14 years ago
*** Bug 245973 has been marked as a duplicate of this bug. ***

Comment 54

14 years ago
*** Bug 251090 has been marked as a duplicate of this bug. ***
I've verified that all testcases in this bug no longer crash for me using build
2004-11-12-04 on Windows XP, Seamonkey trunk.
Status: RESOLVED → VERIFIED

Comment 56

13 years ago
*** Bug 255175 has been marked as a duplicate of this bug. ***

Comment 57

9 years ago
Crashtest added as part of http://hg.mozilla.org/mozilla-central/rev/afc662d52ab1
Flags: in-testsuite+
Crash Signature: [@ 0x00000000 - nsCSSFrameConstructor::FindFrameWithContent ] [@ nsCSSFrameConstructor::FindFrameWithContent ]
You need to log in before you can comment on or make changes to this bug.