Closed
Bug 64702
Opened 24 years ago
Closed 23 years ago
Browser crashes when attempting to fill in a web form.
Categories
(Core :: Layout: Form Controls, defect)
Tracking
()
VERIFIED
FIXED
mozilla0.9
People
(Reporter: rich.burridge, Assigned: pollmann)
References
()
Details
(Keywords: crash, Whiteboard: fix in hand)
Attachments
(8 files)
327 bytes,
text/html
|
Details | |
5.37 KB,
patch
|
Details | Diff | Splinter Review | |
5.38 KB,
patch
|
Details | Diff | Splinter Review | |
12.28 KB,
patch
|
Details | Diff | Splinter Review | |
21.24 KB,
patch
|
Details | Diff | Splinter Review | |
21.98 KB,
patch
|
Details | Diff | Splinter Review | |
340 bytes,
text/html
|
Details | |
784 bytes,
patch
|
Details | Diff | Splinter Review |
* Go to: http://www.telewest.co.uk/hsi/register/interest_form.html Set the Title field to "Mr", then click on the "submit" button. * A popup appears saying that the firstname field" is not given. Click Ok on the popup and then the browser crashes. This was using Netscape 6 on Solaris 8 (SPARC).
Comment 1•24 years ago
|
||
I can repro this on linux with today's build 011008 not sure if this is useful but talkback says nsHTMLInputElement::SetFocus() nsHTMLInputElement::Focus() HTMLInputElementFocus() js_Invoke() js_Interpret() js_Invoke() js_InternalInvoke() JS_CallFunctionValue() nsJSContext::CallEventHandler() nsJSEventListener::HandleEvent() nsEventListenerManager::HandleEventSubType() nsEventListenerManager::HandleEvent() nsGenericElement::HandleDOMEvent() nsHTMLFormElement::HandleDOMEvent() PresShell::HandleDOMEventWithTarget() nsImageControlFrame::MouseClicked() nsHTMLInputElement::HandleDOMEvent() PresShell::HandleEventInternal() PresShell::HandleEventWithTarget() nsEventStateManager::CheckForAndDispatchClick() nsEventStateManager::PostHandleEvent() PresShell::HandleEventInternal() PresShell::HandleEvent() nsView::HandleEvent() nsViewManager2::DispatchEvent() HandleEvent() nsWidget::DispatchEvent() nsWidget::DispatchWindowEvent() nsWidget::DispatchMouseEvent() nsWidget::OnButtonReleaseSignal() nsWindow::HandleGDKEvent() dispatch_superwin_event() handle_gdk_event() libgdk-1.2.so.0 + 0x174db (0x405fb4db) libglib-1.2.so.0 + 0x10186 (0x40628186) libglib-1.2.so.0 + 0x10751 (0x40628751) libglib-1.2.so.0 + 0x108f1 (0x406288f1) libgtk-1.2.so.0 + 0x8c5b9 (0x405505b9) nsAppShell::Run() nsAppShellService::Run() main1() main() libc.so.6 + 0x189cb (0x4023d9cb) maybe we can blame it on the line number http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/html/content/src/nsHTMLInputElement.cpp#666 over to layout.
Assignee: asa → clayton
Component: Browser-General → Layout
QA Contact: doronr → petersen
Reporter | ||
Comment 2•24 years ago
|
||
Changing the platform|O/S to PC/Linux as this is one of the three tier-1 platforms (it's probably All/All, but we will need further verification for that).
OS: Solaris → Linux
Hardware: Sun → PC
Comment 3•23 years ago
|
||
Reassigning to pollmann and changing component to html forms.
Comment 5•23 years ago
|
||
This is not crashing with a 2001032004 build on WINNT. peterson: Could you try on Linux? If it doesn't crash please close this bug. Thanks.
Assignee | ||
Comment 6•23 years ago
|
||
I have a fix for this in my tree, as part of a larger rewrite of form submission, but it can be separated out if need be. I'll attach a reduced test case momentarily. Basically, what's happening is that when you click to submit this form, form.submit() is being called (which submits the form immediately, and loads the new page without firing the onSubmit handler, the bug), and then also, since you are clicking on an image input, the form is submitted a second time. However, the second submit calls the onsubmit handler, which pops up an alert. (Meanwhile, remember, we have torn down the old page and loaded a new one.) As soon as the alert is dismissed, the text field that the error is for is given focus via a textinput.focus(). Since the text input has gone away, this results in a null pointer reference somewhere along the way. (aPresContext in SetFocus()) The fix is to make form.submit() create a submit event, which will cause the onSubmit handler to get fired, and be cancelled. I suspect this will result in two alert boxes, which is what is required by the spec, because the click event is not cancelled...
Status: NEW → ASSIGNED
Whiteboard: fix in hand
Assignee | ||
Comment 7•23 years ago
|
||
Assignee | ||
Comment 8•23 years ago
|
||
Assignee | ||
Comment 9•23 years ago
|
||
Assignee | ||
Comment 10•23 years ago
|
||
Assignee | ||
Comment 11•23 years ago
|
||
Assignee | ||
Comment 12•23 years ago
|
||
Assignee | ||
Comment 13•23 years ago
|
||
When viewing the reduced test case, the browser will often end up locked up in a bad state that causes it to be unusable and requires a kill and restart: a modal dialog has a grab on all events, but it does not have focus, so it doesn't respond to any events (including a click on the button to dismiss it). Apparently, the reason that we get locked up is because of bad interactions between modal dialogs and the fix for bug 9701, here's a 1 line patch that disables the fix for 9701 and makes verifying that *this* patch works a lot easier: Index: nsPresShell.cpp =================================================================== RCS file: /cvsroot/mozilla/layout/html/base/src/nsPresShell.cpp,v retrieving revision 3.386 diff -u -r3.386 nsPresShell.cpp --- nsPresShell.cpp 2001/04/11 03:07:50 3.386 +++ nsPresShell.cpp 2001/04/12 09:48:56 @@ -2472,7 +2472,8 @@ mFrameManager->SetRootFrame(rootFrame); } - CheckForFocus(mDocument); +// XXX We don't want to steal focus from modal dialogs. +// CheckForFocus(mDocument); // Have the style sheet processor construct frame for the root // content object down I've found my browser locked up in this state quite a few times in the past - is there any way to check that there is no modal dialog up before giving focus?
Assignee | ||
Comment 14•23 years ago
|
||
Assignee | ||
Comment 15•23 years ago
|
||
Comment 16•23 years ago
|
||
The fix looks like the right thing to do. r=rods
Assignee | ||
Comment 17•23 years ago
|
||
David is taking over the focus lockup problem as bug 75845. I'll check in the remainder of the fix here...
Assignee | ||
Comment 18•23 years ago
|
||
Fix for crash and early submit checked in. To verify, view the original test case and follow steps above: Set title field to Mr. Scroll down and click on "Submit" button This time, you should not see a crash, and you should not see the browser go forward to an error page. (The browser may lock up and become unusable. This is broken out as bug 75845.)
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•