255153 - Account Wizard crashes after clicking Next -Trunk [@ nsTextControlFrame::SetValue]

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Frank Wein [:mcsmurf]]

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 :/

Comment 1

[Frank Wein [:mcsmurf]]

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.

Comment 2

[Stephen Donner [:stephend] Not actively reading bugmail]

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

Comment 3

[Frank Wein [:mcsmurf]]

(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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> 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...

Comment 5

[Tobias Fischer]

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. 

Comment 6

[Frank Wein [:mcsmurf]]

(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)

Comment 7

[Boris Zbarsky [:bzbarsky]]

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

Comment 8

[Tobias Fischer]

(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

Comment 9

[Tobias Fischer]

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

Comment 10

[Boris Zbarsky [:bzbarsky]]

Attachment: Fix

Comment 11

[Boris Zbarsky [:bzbarsky]]

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 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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 13

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 155851 [details] [diff] [review]
Fix

Could this crash fix be approved for alpha3?

Comment 14

[Asa Dotzler [:asa]]

Comment on attachment 155851 [details] [diff] [review]
Fix

a=asa for checkin to 1.8a3

Comment 15

[Boris Zbarsky [:bzbarsky]]

Fixed

Comment 16

[Jay Patel [:jay]]

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

Comment 17

[Stephen Donner [:stephend] Not actively reading bugmail]

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=