Opened 9 years ago
Closed 7 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)
Change History (7)
Changed 9 years ago by
Attachment: | RadioButtonBug.html added |
---|
comment:1 Changed 8 years ago by
Milestone: | tbd → 2.0 |
---|---|
Priority: | undecided → low |
Summary: | dijit/form/RadioButton allows multiple elements to be checked → RadioButton: on(rb, "click", cb) fires before old RadioButton unchecked |
comment:3 Changed 8 years ago by
I looked at this some more today. The native behavior of radio buttons (and likely checkboxes) is really weird. My expectation was that
- the
onclick
handler is called - if it *doesn't* call
evt.preventDefault()
then the radio button'schecked
property is set to true
but the actual behavior is:
- the
checked
property is set to true - the
onclick
handler is called - if the
onclick
handler callsevt.preventDefault()
, thechecked
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 7 years ago by
Milestone: | 2.0 → 1.11 |
---|
comment:5 Changed 7 years ago by
Owner: | set to bill |
---|---|
Status: | new → assigned |
comment:6 Changed 7 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
OK... so your code for listening to click events on the widgets is:
That calls logDijitState earlier than we want. I note that this code works correctly:
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