Closed Bug 242709 Opened 21 years ago Closed 21 years ago

Disabling Submit button prevents form from submitting


(Core :: DOM: Events, defect)

Windows XP
Not set





(Reporter: patrick.lien, Assigned: bryner)




(4 keywords)


(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040503 Firefox/0.8.0+ (mmoy-Pentium4a)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a) Gecko/20040503 Firefox/0.8.0+ (mmoy-Pentium4a)

When a submit button's onClick event specifies that the form should be submitted
and then the submit button be disabled, the form never submits.  It's as if the
disabling code is executed first and then the call to submit() ignored.

Reproducible: Always
Steps to Reproduce:
1. Visit Vanguard's login page (
2. Click "OK" to submit (no username and password is necessary, it should submit
anyway and return with an error message)

Actual Results:  
"OK" button becomes disabled.  The form is not submitted and no navigation happens.

Expected Results:  
The form should submit and the site shuld react according to username and
password entered.

This regression started happening sometime around the end of April.  The
following UA's work correctly:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8
Attached file Simple test case
A simplified test case.  If you remove "document.frm.mysubmit.disabled=true;"
from the onClick event, the form will properly submit and you will be direted
to Yahoo.
Assignee: firefox → general
Component: General → Browser-General
Product: Firefox → Browser
QA Contact: general
Version: unspecified → Trunk
This was caused by Brian's Apr 30 checkin for bug 60212 (reverting that checkin
fixes the bug). Confirming and reassigning.
Assignee: general → bryner
Ever confirmed: true
Keywords: regression, testcase
Component: Browser-General → DOM: Events
I'm guessing which -- among this maze of twistly little bugs -- to vote for.

Just confirming a problem returned with May's Firefox/Mac OSX --noted in 
various bugs filed recently-- a "login" button does nothing. 

Same as was a problem some months ago -- nothing happens clicking the button.
Were I to log out of Mozillazine, Firefox would fail to use the Login button.

I can leave the cursor in the entry box, after entering a password, and hit 
Enter, and it's accepted.  

*** Bug 242494 has been marked as a duplicate of this bug. ***
*** Bug 242439 has been marked as a duplicate of this bug. ***
Is the problem that event ordering changed, so that the onclick starts a submit
and then disables, then the uievent cancels the previous submit but doesn't
start the new one?
Flags: blocking1.8a?
Darn, I don't know. I've just gone as far as determining that backing out the
60212 patch fixes this bug and those other two.
Well, the question was more directed at bryner... ;)
This bug also (apparently) makes it impossible to pay for eBay items using
PayPal with Mozilla 1.7. The eBay checkout procedure leads to a PayPal form
where the Pay button is disabled on submit and then the form never submits. 
Asking for blocking1.7 status and adding top100.
Flags: blocking1.7?
Keywords: top100
*** Bug 242785 has been marked as a duplicate of this bug. ***
This is not a problem on the 1.7 branch (it's a regression from a patch that
didn't land on the branch), so there's absolutely no reason it should be
blocking 1.7.

If you have a 1.7 problem, it is NOT this bug.
Flags: blocking1.7?
*** Bug 243073 has been marked as a duplicate of this bug. ***
This bug's not getting a lot of love. For those of you who want functional forms
and spin your own builds, I'll just mention the mods I'm personally running
with. I imagine this patch breaks the new DOMActivate event but it returns forms
to their former glory:

Index: content/html/content/src/nsHTMLInputElement.cpp
RCS file: /cvsroot/mozilla/content/html/content/src/nsHTMLInputElement.cpp,v
retrieving revision 1.342
diff -p -u -r1.342 nsHTMLInputElement.cpp
--- content/html/content/src/nsHTMLInputElement.cpp	3 May 2004 21:48:17 -0000	1.342
+++ content/html/content/src/nsHTMLInputElement.cpp	11 May 2004 01:01:25 -0000
@@ -1596,7 +1596,8 @@ nsHTMLInputElement::HandleDOMEvent(nsIPr
-        case NS_DOMUI_ACTIVATE:
+        // hack for onclick="submit(); this.disabled=true" (bug 242709)
+        case NS_MOUSE_LEFT_CLICK:
           if (mForm && (oldType == NS_FORM_INPUT_SUBMIT ||
                         oldType == NS_FORM_INPUT_IMAGE)) {
@@ -1638,7 +1639,8 @@ nsHTMLInputElement::HandleDOMEvent(nsIPr
         } break;// NS_DOMUI_ACTIVATE
       } //switch
     } else {
-      if (aEvent->message == NS_DOMUI_ACTIVATE &&
+      // hack for onclick="submit(); return false" (bug 242494)
+      if (aEvent->message == NS_MOUSE_LEFT_CLICK &&
           (oldType == NS_FORM_INPUT_SUBMIT || oldType == NS_FORM_INPUT_IMAGE) &&
           mForm) {
         // tell the form to flush a possible pending submission.
Workaround: disabel Java Script.  Go to site and logon.  It will take you to a
page that indicates Java Script is needed.  Enable Java Script.  Click on the
site again.
*** Bug 243272 has been marked as a duplicate of this bug. ***
Encountering the problem using latest Fx builds on WinXP on blog sites that
utilize the comment software from

Hitting the submit  button in the comment portion of it disables the button and
nothing else.
A work around (at least for Vanguard)is as follows:

1. Disable JavaScript
2. Go to site (I click on a bookmark to do this) and login.
   This will result in a screen that says you need JavaScript.
3. Enable javaScript.
4. Click on bookmark again.

Result: your in your account.
*** Bug 243542 has been marked as a duplicate of this bug. ***
This also occurs with:
American Express online payment submission:
and other sites...

It does appear to be a regression in the recent May nightlies. I also confirm
1.7 branch is fine (I've stopped using nightlies as a result.

Are these bugs dups?,,

They all seem to be related to logon / online submission with buttons.
Blocks: 243703
This is a major regression which breaks paypal and plenty of other sites. We
need a fix or the backout of the change which caused it (bug 60212).
Severity: major → blocker
Keywords: smoketest
What sequence do the click and activate events fire in?  Does cancelling the
click event cancel the activate event?

It's sounding to me like the answers are: click fires first and no (dan, can you

If so, click events in these testcases start the submit via submit(), then the
activate event cancels it (or flushes it?) and starts another submit or some
such thing.... and then something breaks.
The patch in comment 13 fixes this problem, and the similar bug 242494. I don't
know what effect it has on DOMActivate events. I remember noticing that in one
case, the first one (the 242709 one) I think, that the DOM_UI_ACTIVATE case
never executed. It's not that it occurred late. It just never happened. I'm not
certain what that says about actual event order, which I haven't looked into.
But I'd hope the patch would indicate something.
dougt: this is the bug that i mentioned (or meant to mention) in an email. i'm
not sure why they haven't backed out the change. i certainly can't leave this
change for my internal builds :(.
Applying private mail filter to previous comment.
Wait, there doesn't seem to be any such filter...
Note patch in bug 242494 
Depends on: 242494
fix checked in with bug 242494
Closed: 21 years ago
Resolution: --- → FIXED
Clearing blocking1.8a? as this has been fixed.
Flags: blocking1.8a?
You need to log in before you can comment on or make changes to this bug.