Browser crashes when attempting to fill in a web form.

VERIFIED FIXED in mozilla0.9

Status

()

Core
Layout: Form Controls
--
major
VERIFIED FIXED
17 years ago
10 years ago

People

(Reporter: Rich Burridge, Assigned: Eric Pollmann)

Tracking

({crash})

Trunk
mozilla0.9
x86
Linux
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fix in hand, URL)

Attachments

(8 attachments)

(Reporter)

Description

17 years ago
* 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

17 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

17 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

17 years ago
Reassigning to pollmann and changing component to html forms.
Assignee: clayton → pollmann
Component: Layout → HTML Form Controls
Keywords: crash

Comment 4

17 years ago
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.
(Assignee)

Comment 6

17 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

17 years ago
Created attachment 29186 [details]
reduced test case (click submit, dismiss alert, crash)
(Assignee)

Comment 8

17 years ago
Created attachment 29895 [details] [diff] [review]
patch - generate (cancellable) submit event for form.submit()
(Assignee)

Comment 9

17 years ago
Created attachment 29897 [details] [diff] [review]
updated patch - fix two typos (oops, old patch!)
(Assignee)

Comment 10

17 years ago
Created attachment 30401 [details] [diff] [review]
updated patch, removes manual notification of frame in DoManualSubmitReset
(Assignee)

Comment 11

17 years ago
Created attachment 30551 [details] [diff] [review]
patch 4, also fixes reduced test case and related problems
(Assignee)

Comment 12

17 years ago
Created attachment 30555 [details] [diff] [review]
patch 5, refactor focus and blur methods
(Assignee)

Comment 13

17 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

17 years ago
Created attachment 30557 [details]
non-crasher test case for lock-up bug.
(Assignee)

Comment 15

17 years ago
Created attachment 30559 [details] [diff] [review]
patch 6, fix focus lock-up problem

Comment 16

17 years ago
The fix looks like the right thing to do. r=rods
(Assignee)

Comment 17

17 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

17 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
Last Resolved: 17 years ago
Resolution: --- → FIXED

Updated

17 years ago
Blocks: 77421

Comment 19

17 years ago
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.