Dispatching a 'click' event immediately after removing "disabled" property on a form element doesn't work

NEW
Unassigned

Status

()

Core
DOM: Events
P3
normal
5 years ago
25 days ago

People

(Reporter: Jan Dudek, Unassigned)

Tracking

(Depends on: 1 bug, {testcase})

Trunk
x86
Mac OS X
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.77 Safari/537.36

Steps to reproduce:

* Create an HTML form with <input type="submit" disabled>
* In JavaScript:
    * Change the property "disabled" of input to false
    * Trigger a "click" event on the input

Here's a JSFiddle with the above: http://jsfiddle.net/jdudek/7XK2Q/5/

Here's my earlier fiddle that does the same with jQuery: http://jsfiddle.net/jdudek/7XK2Q/2/

Adding window.setTimeout() between change of "disabled" and triggering a click solves the problem. (Minimum of 10ms worked for me).


Actual results:

The form is not submitted. (Its event handler for "submit" is not triggered).


Expected results:

The form should be submitted. (Its event handler for "submit" should be triggered).

Comment 1

3 years ago
Confirmed on the current nightly. Chrome works as expected with this testcase.

Note that the testcase removes 'disabled' and synthesizes the event on load, so the 'submitted' text should appear when the page is loaded, not after you click the Submit button.

I've stumbled on this bug while searching for a similar bug, where removing 'disabled' from an <input type=checkbox> and immediately calling .click() on it had no effect.

This might change when bug 329509 is fixed.
Status: UNCONFIRMED → NEW
Depends on: 329509
Ever confirmed: true
Keywords: testcase
Summary: Can't submit form immediately after removing "disabled" property → Dispatching a 'click' event immediately after removing "disabled" property on a form element doesn't work
Version: 26 Branch → Trunk

Comment 2

3 years ago
Created attachment 8640824 [details]
testcase from the reporter

Updated

5 months ago
Duplicate of this bug: 1426856

Updated

5 months ago
See Also: → bug 1443148

Comment 4

5 months ago
Copying relevant comment from the dupe:

(In reply to Olli Pettay [:smaug] (unusual timezone [JST] for a week) from bug 1443148 comment #6)
> Isn't this a dup... We don't flush the layout so 
> https://searchfox.org/mozilla-central/rev/
> 51cd1093c5c2113e7b041e8cc5c9bf2186abda13/layout/style/res/forms.css#432
> still applies.
> https://searchfox.org/mozilla-central/rev/
> 51cd1093c5c2113e7b041e8cc5c9bf2186abda13/dom/html/nsGenericHTMLElement.
> cpp#2292
> 
> I don't have good ideas how to fix this though. We don't want to flush
> layout all the time.
> Or, hmm, perhaps we could flush style when changing disabled state.

Updated

25 days ago
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.