Closed Bug 28988 Opened 25 years ago Closed 25 years ago

crash when visiting www.jeep.com

Categories

(Core :: DOM: Core & HTML, defect, P3)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: dougt, Assigned: pollmann)

References

Details

(Keywords: crash, Whiteboard: [PDT+] w/b minus on 3/10 - Need build later than 3/9 to verify) 

I am trying to get a price for a jeep, and I crash:

nsVoidArray::Count() line 43 + 3 bytes
nsEventListenerManager::HandleEvent(nsIPresContext * 0x04b6bf10, nsEvent * 
0x0012f780, nsIDOMEvent * * 0x0012f734, unsigned int 0x00000007, nsEventStatus * 
0x0012f7a0) line 1124 + 42 bytes
nsGenericElement::HandleDOMEvent(nsIPresContext * 0x04b6bf10, nsEvent * 
0x0012f780, nsIDOMEvent * * 0x0012f734, unsigned int 0x00000001, nsEventStatus * 
0x0012f7a0) line 1010
nsHTMLFormElement::HandleDOMEvent(nsHTMLFormElement * const 0x049be0d0, 
nsIPresContext * 0x04b6bf10, nsEvent * 0x0012f780, nsIDOMEvent * * 0x00000000, 
unsigned int 0x00000001, nsEventStatus * 0x0012f7a0) line 465
nsImageControlFrame::MouseClicked(nsIPresContext * 0x04b6bf10) line 456
nsImageControlFrame::HandleEvent(nsImageControlFrame * const 0x032a9e9c, 
nsIPresContext * 0x04b6bf10, nsGUIEvent * 0x0012fad4, nsEventStatus * 
0x0012f9e0) line 305
PresShell::HandleEvent(PresShell * const 0x04b66be4, nsIView * 0x04a592f0, 
nsGUIEvent * 0x0012fad4, nsEventStatus * 0x0012f9e0) line 2950 + 38 bytes
nsView::HandleEvent(nsView * const 0x04a592f0, nsGUIEvent * 0x0012fad4, unsigned 
int 0x00000008, nsEventStatus * 0x0012f9e0, int & 0x00000000) line 799
nsView::HandleEvent(nsView * const 0x04bb1a40, nsGUIEvent * 0x0012fad4, unsigned 
int 0x00000008, nsEventStatus * 0x0012f9e0, int & 0x00000000) line 784
nsView::HandleEvent(nsView * const 0x04bb0230, nsGUIEvent * 0x0012fad4, unsigned 
int 0x00000008, nsEventStatus * 0x0012f9e0, int & 0x00000000) line 784
nsView::HandleEvent(nsView * const 0x04b657a0, nsGUIEvent * 0x0012fad4, unsigned 
int 0x0000001c, nsEventStatus * 0x0012f9e0, int & 0x00000000) line 784
nsViewManager2::DispatchEvent(nsViewManager2 * const 0x04b65a20, nsGUIEvent * 
0x0012fad4, nsEventStatus * 0x0012f9e0) line 1216
HandleEvent(nsGUIEvent * 0x0012fad4) line 69
nsWindow::DispatchEvent(nsWindow * const 0x04bb0114, nsGUIEvent * 0x0012fad4, 
nsEventStatus & nsEventStatus_eIgnore) line 493 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fad4) line 514
nsWindow::DispatchMouseEvent(unsigned int 0x0000012d, nsPoint * 0x00000000) line 
2938 + 21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 0x0000012d, nsPoint * 0x00000000) 
line 3156
nsWindow::ProcessMessage(unsigned int 0x00000202, unsigned int 0x00000000, long 
0x007a004b, long * 0x0012fd60) line 2243 + 24 bytes
nsWindow::WindowProc(HWND__ * 0x009504e4, unsigned int 0x00000202, unsigned int 
0x00000000, long 0x007a004b) line 671 + 27 bytes
USER32! 77e71820()
00



Steps to reproduce:

1. goto http://www.jeepunpaved.com/grand_cherokee/frameset_grand_cherokee.html
2. click CA in popdown list
3. click the select button.
moving to form submission after looking at the stack.
Component: Browser-General → Form Submission
updating component owner
Assignee: cbegle → karnaze
QA Contact: asadotzler → ckritzer
Reassigning to Joki.
Assignee: karnaze → joki
Severity: normal → critical
Keywords: crash
Marking M17.
Target Milestone: M17
I can't buy my jeep until m17?!  Adding beta1 to the keywords.
Keywords: beta1
I'm sorry, I'm not seeing a dropdown with CA in it at that URL?  Little help?
click on "Price" at the top of the page.

This works in today's debug build
I am using this morning commercial build, and the crash still happens.
[PDT+] w/b minus on 3/10
Whiteboard: [PDT+] w/b minus on 3/10
I've looked at this a bit and can add some detail:

When we get to the loop at nsEventListenerManager.cpp:1124,
mFormListeners->Count() is 1.  But when we get to the end of the loop at line
1195 after calling HandleEventSubType(), things have gotten fouled up, and when
we get back to the loop to check, mFormListeners is now null and we crash when
we dereference it.

Guarding against that by storing the count in a local variable doesn't help;
then we crash a bit later, after asserting " No document found in Form Submit!"
followed by an assertion about dereferencing a null nsCOMPtr.  So I guess
mFormListeners isn't the only thing getting stomped.

Okay, fix in hand.  Looking for checkin approval person.
Status: NEW → ASSIGNED
Whiteboard: [PDT+] w/b minus on 3/10 → [PDT+] fix in hand, w/b minus on 3/10
*** Bug 29175 has been marked as a duplicate of this bug. ***
Okay, closing a window during onsubmit, or any other event should be okay now.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Whiteboard: [PDT+] fix in hand, w/b minus on 3/10 → [PDT+] w/b minus on 3/10
This sucks but I have to reopen this.  When I put the the fix for the crashing 
stack listed below I ran into another crash in nsFormFrame::OnSubmit due to a 
null document.  I thought I could fix that by mucking with the event's 
consumption state but I was wrong.  Painfully wrong.  Anyway, I'm reopening this 
and giving it to the 'owner' of the nsFormFrame stuff.  Seems like its either 
pollmann or karnaze.  Since I've given pollmann a fair number of bugs this one 
goes to karnaze.  I'll just cc pollmann.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Actually, I changed my mind.  Giving to pollmann after all.  
nsFormFrame::OnSubmit needs to be made safe in the case where the document has 
disappeared.
Assignee: joki → pollmann
Status: REOPENED → NEW
I think it might be safest to just exit when we realize there is no document in
form submit (return NS_OK);  There is not going to be any way to determine what
URL we should submit to anyway.  I've remove the assert there, and turned it
into return NS_OK.  I'll test this and see if it fixes the crash.
Status: NEW → ASSIGNED
Yep, that does the trick - no more assertions/crashes.

The problem was that after we updated the opening window's URL and then closed
ourself, we still tried to submit because they didn't return FALSE in the
OnSubmit handler like they should have.  The check-for-null I just added in
nsFormFrame::OnSubmit prevents this from happening.
Whiteboard: [PDT+] w/b minus on 3/10 → [PDT+] w/b minus on 3/10, fix in hand, need approval
Fix checked in.  To verify, go to the jeep page in question and go get a price
quit, you should not see a crash.  Thanks!
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Whiteboard: [PDT+] w/b minus on 3/10, fix in hand, need approval → [PDT+] w/b minus on 3/10
s/quit/quote/.  Apparently my typing skills could use some improvement. ;)
Whiteboard: [PDT+] w/b minus on 3/10 → [PDT+] w/b minus on 3/10 - Need build later than 3/9 to verify
awesome, now I can buy a jeep... wonder if I can expense this for testing
purposes...  :-)

If you find out you can, let me know, because I had two buy three in the course
of fixing this bug.  ;)
Verified with 03-10-09
Status: RESOLVED → VERIFIED
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.