Opened 7 years ago

Closed 7 years ago

#17082 closed defect (wontfix)

[regression] Firefox: Button: can't be programmatically triggered immediately after changing disabled to false

Reported by: liucougar Owned by: Douglas Hays
Priority: low Milestone: 1.9
Component: Dijit - Form Version: 1.9.0rc2
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by liucougar)

put the following file under dijit dir, and load it in Firefox, click the second button, the first no alert shows. However, try the same file with chrome or IE, or with dijit 1.8.3, the alert properly shows.

<html>
<head>
<link href="../dijit/themes/claro/claro.css" type="text/css" rel="stylesheet"/>
<script src="..//dojo/dojo.js" data-dojo-config="async: 1"></script>
<script>
require(["dijit/form/Button"], function(Button){
    var button = new Button({label:'disabled', disabled: true, onClick:function(){
        alert('first button is clicked');
        button.set('disabled', true);
    }});
    document.body.appendChild(button.domNode);
    
    var pb = new Button({label:'click me to enable and click the disabled button', onClick: function(){
        button.set('disabled', false);
        button.focusNode.click();
    }});
    document.body.appendChild(pb.domNode);
});
</script>
</head>
<body class="claro">
</body>
</html>

this is a regression from 1.8.3, only affect firefox (tested with 19 and 20)

Change History (9)

comment:1 Changed 7 years ago by liucougar

it looks like #15097 is the likely cause of this: in Firefox, when setting valueNode.disabled from true to false, and immediately call valueNode.click(), it somehow does not trigger onclick event on valueNode.

this breaks our functional tests (which waits for some button to be enabled, and then clicks it)

Last edited 7 years ago by liucougar (previous) (diff)

comment:2 Changed 7 years ago by liucougar

Description: modified (diff)

comment:3 Changed 7 years ago by bill

I do see the difference in behavior between firefox and chrome, that the alert doesn't show up on firefox.

But I don't see any regression. On FF/mac and FF/windows XP, I don't get the alert even when running the test case on 1.8 (latest) or on 1.8.0.

Are you sure that test case above, when run against Dojo 1.8, shows the alert for you on FF?

comment:4 Changed 7 years ago by liucougar

i tried in both 1.8.3 with jsfiddle (at http://jsfiddle.net/Sg2f5/1/ ) and checked out 1.8.0 tag in my local git repo, and this bug does not reproduce in either of these

comment:5 Changed 7 years ago by bill

OK, sorry my mistake. Yes, the behavior on FF changed in [29962].

Version 0, edited 7 years ago by bill (next)

comment:6 Changed 7 years ago by bill

Summary: [regression] Button can't be programmatically triggered after change disabled to false[regression] Button: can't be programmatically triggered immediately after changing disabled to false

Note also that if you give some time between enabling the button and clicking it, things work fine:

button.set('disabled', false);
setTimeout(function(){ button.focusNode.click(); }, 1);

Surprisingly 0ms doesn't work.

I'm not sure why we even disable this.valueNode in the first place but probably there's a reason. So I'm not sure there's anything that can be done for this other than documenting it in the release notes. It really seems like a corner case to me. Does it affect user interaction (like hitting return to submit a form) or is it just something about automated tests?

comment:7 Changed 7 years ago by liucougar

this is caused by a Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=432096

one workaround is to use <button> instead of <input type=button> in button template

one sample is here: http://jsfiddle.net/Sg2f5/2/

click the second button in the second row, and it works fine in Firefox

doughays, do you see any problems with this change?

comment:8 Changed 7 years ago by Douglas Hays

Summary: [regression] Button: can't be programmatically triggered immediately after changing disabled to false[regression] Firefox: Button: can't be programmatically triggered immediately after changing disabled to false

I don't foresee a technical problem changing the hidden INPUT to a BUTTON, however I'd think there would be backward compatibility issues with users using query to find INPUT elements. Because this is a corner case and obviously a Firefox bug, I suggest affected users adding the following style workaround:

.dj_gecko .dijitButton input.dijitOffScreen {
        -moz-user-input: enabled;
}

liucougar, does this work for you?

comment:9 Changed 7 years ago by liucougar

Milestone: tbd1.9
Priority: undecidedlow
Resolution: wontfix
Status: newclosed

that workaround does work for us. i will close this ticket.

thanks for the suggestion.

Note: See TracTickets for help on using tickets.