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
•