This happens with a current cvs trunk build To reproduce: 1. Start MailNews 2. Open Mail&News Account Settings 3. Click on Add Account 4. Fill in some random (valid data) After entering the Incoming Server (POP, Use Global Inbox deactivated, but i don't think this is related) and pressing the Next button, it crashes. Stacktrace: nsTextControlFrame::SetValue(nsTextControlFrame * const 0x06353c20, const nsAString & {...}) line 2961 + 9 bytes nsTextControlFrame::SetProperty(nsTextControlFrame * const 0x06382aa8, nsPresContext * 0x06137310, nsIAtom * 0x00e84b10, const nsAString & {...}) line 2156 nsHTMLInputElement::SetValueInternal(nsHTMLInputElement * const 0x06353c20, const nsAString & {...}, nsITextControlFrame * 0x00000001) line 708 nsHTMLInputElement::SetValue(nsHTMLInputElement * const 0x0681d714, const nsAString & {...}) line 660 XPTC_InvokeByIndex(nsISupports * 0x0681d714, unsigned int 0x00000058, unsigned int 0x00000001, nsXPTCVariant * 0x0012b9cc) line 102 XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNative::CallMode 0xaf02a468) line 2028 + 22 bytes XPC_WN_GetterSetter(JSContext * 0x0620b9e8, JSObject * 0x02ce2f50, unsigned int 0x00000001, long * 0x02ce3244, long * 0x0012bc28) line 1311 + 11 bytes js_Invoke(JSContext * 0x00000001, unsigned int 0x00000001, unsigned int 0x00000002) line 1281 + 17 bytes js_InternalInvoke(JSContext * 0x041fd230, JSObject * 0x0602a468, long 0x0419eac0, unsigned int 0x00000000, unsigned int 0x00000001, long * 0x0012bebc, long * 0x0012bebc) line 1378 + 13 bytes js_InternalGetOrSet(JSContext * 0x0620b9e8, JSObject * 0x0602a468, long 0x00ea49e0, long 0x0419eac0, int 0x00000008, unsigned int 0x00000001, long * 0x0012bebc, long * 0x0012bebc) line 1421 + 21 bytes js_SetProperty(JSContext * 0x0620b9e8, JSObject * 0x0602a468, long 0x00ea49e0, long * 0x0012bebc) line 2884 + 33 bytes js_Interpret(JSContext * 0x0620b9e8, long * 0x0012bf64) line 2531 js_Invoke(JSContext * 0x00000001, unsigned int 0x00000001, unsigned int 0x00000002) line 1301 + 10 bytes js_InternalInvoke(JSContext * 0x041fd20c, JSObject * 0x06d64ac0, long 0x06d64690, unsigned int 0x00000000, unsigned int 0x00000001, long * 0x0012c190, long * 0x0012c190) line 1378 + 13 bytes js_InternalGetOrSet(JSContext * 0x0620b9e8, JSObject * 0x06d64ac0, long 0x00ea49e0, long 0x06d64690, int 0x00000008, unsigned int 0x00000001, long * 0x0012c190, long * 0x0012c190) line 1421 + 21 bytes js_SetProperty(JSContext * 0x0620b9e8, JSObject * 0x06d64ac0, long 0x00ea49e0, long * 0x0012c190) line 2884 + 33 bytes js_Interpret(JSContext * 0x0620b9e8, long * 0x0012c238) line 2531 js_Invoke(JSContext * 0x00000001, unsigned int 0x00000001, unsigned int 0x00000006) line 1301 + 10 bytes fun_apply(JSContext * 0x0620b9e8, JSObject * 0x06d64a50, unsigned int 0x00000001, long * 0x00000001, long * 0x0012c2b0) line 1532 js_Invoke(JSContext * 0x00000001, unsigned int 0x00000002, unsigned int 0x00000000) line 1281 + 17 bytes js_Interpret(JSContext * 0x0620b9e8, long * 0x0012c4e8) line 3375 + 11 bytes js_Invoke(JSContext * 0x00000001, unsigned int 0x00000001, unsigned int 0x00000002) line 1301 + 10 bytes js_InternalInvoke(JSContext * 0x041fd064, JSObject * 0x06861188, long 0x06861240, unsigned int 0x00000000, unsigned int 0x00000001, long * 0x0012c714, long * 0x0012c714) line 1378 + 13 bytes js_InternalGetOrSet(JSContext * 0x0620b9e8, JSObject * 0x06861188, long 0x06859c48, long 0x06861240, int 0x00000008, unsigned int 0x00000001, long * 0x0012c714, long * 0x0012c714) line 1421 + 21 bytes js_SetProperty(JSContext * 0x0620b9e8, JSObject * 0x06861188, long 0x06859c48, long * 0x0012c714) line 2884 + 33 bytes js_Interpret(JSContext * 0x0620b9e8, long * 0x0012c7bc) line 2531 js_Invoke(JSContext * 0x00000001, unsigned int 0x00000000, unsigned int 0x00000000) line 1301 + 10 bytes js_Interpret(JSContext * 0x0620b9e8, long * 0x0012c98c) line 3375 + 11 bytes js_Invoke(JSContext * 0x00000001, unsigned int 0x00000001, unsigned int 0x00000002) line 1301 + 10 bytes nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJSClass * const 0x01d3e188, nsXPCWrappedJS * 0x01fb7a98, unsigned short 0x0003, const nsXPTMethodInfo * 0x01c376e8, nsXPTCMiniVariant * 0x0012cb30) line 1336 + 16 bytes nsXPCWrappedJS::CallMethod(nsXPCWrappedJS * const 0x03fb7a98, unsigned short 0x0003, const nsXPTMethodInfo * 0x01c376e8, nsXPTCMiniVariant * 0x0012cb30) line 450 PrepareAndDispatch(nsXPTCStubBase * 0x00000000, unsigned int 0x00000003, unsigned int * 0x0012cbe8, unsigned int * 0x0012cbd8) line 117 + 18 bytes SharedStub() line 147 nsEventListenerManager::HandleEventSubType(nsEventListenerManager * const 0x06353c20, nsListenerStruct * 0x03fb7c88, nsIDOMEvent * 0x060f5578, nsIDOMEventTarget * 0x06d189f0, unsigned int 0x060f5584, unsigned int 0x00000007) line 1512 + 11 bytes nsEventListenerManager::HandleEvent(nsEventListenerManager * const 0x03fb7c50, nsPresContext * 0x00000000, nsEvent * 0x00000000, nsIDOMEvent * * 0x0012cfa4, nsIDOMEventTarget * 0x06d189f0, unsigned int 0x00000007, nsEventStatus * 0x0012d0f8) line 1590 nsXULElement::HandleDOMEvent(nsXULElement * const 0x06353c20, nsPresContext * 0x06137310, nsEvent * 0x0012d0ac, nsIDOMEvent * * 0x0012cfa4, unsigned int 0x00000007, nsEventStatus * 0x0012d0f8) line 2823 PresShell::HandleDOMEventWithTarget(PresShell * const 0x06e90100, nsIContent * 0x06e90100, nsEvent * 0x0012d0ac, nsEventStatus * 0x0012d0f8) line 6090 nsButtonBoxFrame::MouseClicked(nsButtonBoxFrame * const 0x06353c20, nsPresContext * 0x06137310, nsGUIEvent * 0x0012d1e8) line 178 nsButtonBoxFrame::HandleEvent(nsButtonBoxFrame * const 0x06eb2680, nsPresContext * 0x06137310, nsGUIEvent * 0x0012d1e8, nsEventStatus * 0x0012d5a4) line 147 This makes creating new accounts impossible in MailNews :/

Ok, you need to create a mail account to reproduce, with a news account it doesn't crash. The problem here is mEditor is a null pointer.

This smells like bug 27382 landing/backing out fallout. Have you tried with a new build since then?

(In reply to comment #2) > This smells like bug 27382 landing/backing out fallout. Have you tried with a > new build since then? Yes, my build has all checkins up-to now.

> The problem here is mEditor is a null pointer. The entire SetValue() function is one big |if (mEditor && mUseEditor)| block. So we shouldn't be getting into this code at all if mEditor is null. Can you narrow down a 24-hour period for the regression using nightlies, at least? That'll give us a place to start looking...

Last known good here was Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3) Gecko/20040809 Mnenhy/0.6.0.104 {Build ID: 2004080918} Tinderbox-Build. I missed some Builds, next available here is 2004081008 which crashes. I have got an crash too while try to Open the All-Header View with mnenhy, the Stack look a bit similar, send some Talkback-Reports: TB537356Y Hope thats the same Regression.

(In reply to comment #4) > Can you narrow down a 24-hour period for the regression using nightlies, at > least? That'll give us a place to start looking... Can confirm Comment 5, doesn't occour with 2004080908, but with 2004081008 Bonsai link: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004%2F08%2F09+07%3A00%3A00&maxdate=2004%2F08%2F10+09%3A00%3A00&cvsroot=%2Fcvsroot (-1 hours at 09 build, +1 hour at 10 build, just not so miss some maybe checkin, since i dont know if the hour is the beginning of the build process or if it marks the end of it)

Is this a problem in an August 11 build? The August 10 builds were done mid-checkin, apparently, and were rather bogus..

(In reply to comment #7) > Is this a problem in an August 11 build? Yes, it is. I have tried it with: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3) Gecko/20040811 Mnenhy/0.6.0.104 {Build ID: 2004081109} and can reproduce my crash while try to expand Headers: TB538334M and try to make an new E-Mail Account like the original reporting: TB538315K

Oops, sorry for the Spam, I have confused the two Talkback IDs im comment #8

Comment on attachment 155851 [details] [diff] [review] Fix David, could you review? The short story here is that setting .value on the content node passed the value on to the frame, which was still around but would get destroyed if style got flushed. Then the frame sets the value in the editor, which does a reflow batch around the operation; the end of the reflow batch flushes out reflow (and hence style reresolves), which destroys the frame. Then we unwind back into the frame and attempt to access members, which crashes... The fix is to change nsGenericHTMLElement::GetPrimaryFrameFor to never return a frame that's on the hit list...

Comment on attachment 155851 [details] [diff] [review] Fix This is confusing without knowing that Flush_Frames is a bunch of other things |ed together (including Flush_StyleReresolves), but r+sr=dbaron.

Comment on attachment 155851 [details] [diff] [review] Fix Could this crash fix be approved for alpha3?

Comment on attachment 155851 [details] [diff] [review] Fix a=asa for checkin to 1.8a3

Fixed

Adding topcrash keyword for tracking. This was a MozillaTrunk regression introduced on 8/10 and should no longer appear in Talkback data after 8/12. We can keep an eye on Talkback data and verify this in a few days: http://talkback-public.mozilla.org/reports/mozilla/Trunk/Trunk-topcrashers.html

The last date on the Talkback crashers is 2004-08-11, which means this was definitely fixed in the 12th builds: http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=nsTextControlFrame%3A%3ASetValue&vendor=All&product=All&platform=All&buildid=&sdate=&stime=&edate=&etime=