Closed
Bug 28988
Opened 25 years ago
Closed 25 years ago
crash when visiting www.jeep.com
Categories
(Core :: DOM: Core & HTML, defect, P3)
Core
DOM: Core & HTML
Tracking
()
VERIFIED
FIXED
M17
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.
Reporter | ||
Comment 1•25 years ago
|
||
moving to form submission after looking at the stack.
Component: Browser-General → Form Submission
Comment 2•25 years ago
|
||
updating component owner
Assignee: cbegle → karnaze
QA Contact: asadotzler → ckritzer
Reporter | ||
Comment 5•25 years ago
|
||
I can't buy my jeep until m17?! Adding beta1 to the keywords.
Keywords: beta1
Comment 6•25 years ago
|
||
I'm sorry, I'm not seeing a dropdown with CA in it at that URL? Little help?
Reporter | ||
Comment 7•25 years ago
|
||
click on "Price" at the top of the page.
Comment 8•25 years ago
|
||
This works in today's debug build
Reporter | ||
Comment 9•25 years ago
|
||
I am using this morning commercial build, and the crash still happens.
Comment 11•25 years ago
|
||
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.
Comment 12•25 years ago
|
||
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
Comment 13•25 years ago
|
||
*** Bug 29175 has been marked as a duplicate of this bug. ***
Comment 14•25 years ago
|
||
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
Comment 15•25 years ago
|
||
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 → ---
Comment 16•25 years ago
|
||
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
Assignee | ||
Comment 17•25 years ago
|
||
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
Assignee | ||
Comment 18•25 years ago
|
||
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
Assignee | ||
Comment 19•25 years ago
|
||
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
Assignee | ||
Comment 20•25 years ago
|
||
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
Reporter | ||
Comment 21•25 years ago
|
||
awesome, now I can buy a jeep... wonder if I can expense this for testing purposes... :-)
Assignee | ||
Comment 22•25 years ago
|
||
If you find out you can, let me know, because I had two buy three in the course of fixing this bug. ;)
Updated•6 years ago
|
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•