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)

x86
Linux
defect
Not set
major

Tracking

()

VERIFIED FIXED
mozilla0.9

People

(Reporter: rich.burridge, Assigned: pollmann)

References

()

Details

(Keywords: crash, Whiteboard: fix in hand)

Attachments

(8 files)

* 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).
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
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
Reassigning to pollmann and changing component to html forms.
Assignee: clayton → pollmann
Component: Layout → HTML Form Controls
Keywords: crash
Moving to m0.9.
Target Milestone: --- → mozilla0.9
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.
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
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?
The fix looks like the right thing to do. r=rods
David is taking over the focus lockup problem as bug 75845.  I'll check in the
remainder of the fix here...
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
Blocks: 77421
Marking verified in the May 22nd build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: