Closed Bug 28988 Opened 25 years ago Closed 25 years ago

crash when visiting www.jeep.com

Categories

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

defect

Tracking

()

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