Opened 5 years ago

Closed 4 years ago

#17613 closed defect (fixed)

RadioButton: on(rb, "click", cb) fires before old RadioButton unchecked

Reported by: Mangala Sadhu Sangeet Singh Khalsa Owned by: bill
Priority: low Milestone: 1.11
Component: Dijit - Form Version: 1.9.1
Keywords: Cc:
Blocked By: Blocking:

Description

There is a brief window of time wherein more than one RadioButton? element (in the same named group) can be checked. During the processing of the 'click' event the clicked element is checked, but the previously checked element is also still checked.

See attached example to compare DOM and Dijit behavior.

Attachments (1)

RadioButtonBug.html (2.6 KB) - added by Mangala Sadhu Sangeet Singh Khalsa 5 years ago.

Download all attachments as: .zip

Change History (7)

Changed 5 years ago by Mangala Sadhu Sangeet Singh Khalsa

Attachment: RadioButtonBug.html added

comment:1 Changed 5 years ago by bill

Milestone: tbd2.0
Priority: undecidedlow
Summary: dijit/form/RadioButton allows multiple elements to be checkedRadioButton: on(rb, "click", cb) fires before old RadioButton unchecked

OK... so your code for listening to click events on the widgets is:

on(dijit1, 'click', logDijitState);
on(dijit2, 'click', logDijitState);
on(dijit3, 'click', logDijitState);

That calls logDijitState earlier than we want. I note that this code works correctly:

on(dijit1.domNode, 'click', logDijitState);
on(dijit2.domNode, 'click', logDijitState);
on(dijit3.domNode, 'click', logDijitState);

I guess it's got something to do with when logDijitState() is called relative to when the browser executes its default action (to clear the other radio button).

In any case, I think this will be fixed for 2.0 when we implement widgets as custom elements

comment:3 Changed 4 years ago by bill

I looked at this some more today. The native behavior of radio buttons (and likely checkboxes) is really weird. My expectation was that

  1. the onclick handler is called
  2. if it *doesn't* call evt.preventDefault() then the radio button's checked property is set to true

but the actual behavior is:

  1. the checked property is set to true
  2. the onclick handler is called
  3. if the onclick handler calls evt.preventDefault(), the checked property is reverted to false

The so-called preventDefault() method isn't preventing anything, but rather reverting what has already been done.

Anyway, I see that the PR is implementing that same behavior. I don't like it, but I guess it's good to match native behavior. So, probably I can accept it.

comment:4 Changed 4 years ago by dylan

Milestone: 2.01.11

comment:5 Changed 4 years ago by bill

Owner: set to bill
Status: newassigned

comment:6 Changed 4 years ago by Bill Keese <bill@…>

Resolution: fixed
Status: assignedclosed

In 6d17a2a7040d20712a0aa6cc29211ca9730d0909/dijit:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 
Note: See TracTickets for help on using tickets.