#17399 closed defect (fixed)
Items of disabled CheckedMultiSelect not disabled
| Reported by: | haysmark | Owned by: | haysmark |
|---|---|---|---|
| Priority: | high | Milestone: | 1.6.3 |
| Component: | DojoX Form | Version: | 1.6.1 |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: |
Description
See the attached modified test case.
When you declare a CheckedMultiSelect? in markup, it calls the methods _setDisabledAttr and _setReadOnlyAttr before it registers its children. This puts the widget in a weird state where the parent is disabled but its children are not.
A simple solution would be to explicitly invoke set("disabled") and set("readOnly") in startup so that the children exist.
Attachments (1)
Change History (32)
Changed 6 years ago by
| Attachment: | test_CheckedMultiSelect.html added |
|---|
comment:2 Changed 6 years ago by
| Owner: | set to haysmark |
|---|---|
| Status: | new → assigned |
comment:3 Changed 6 years ago by
| Milestone: | tbd → 1.10 |
|---|---|
| Priority: | undecided → high |
comment:4 Changed 6 years ago by
| Milestone: | 1.10 → 1.6.2 |
|---|
comment:5 Changed 6 years ago by
| Version: | 1.9.1 → 1.6.1 |
|---|
comment:6 Changed 6 years ago by
| Milestone: | 1.6.2 → 1.6.3 |
|---|
Retargeting all open 1.6.2 tickets to next 1.6.x milestone.
comment:7 Changed 6 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
comment:8 Changed 6 years ago by
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
comment:9 Changed 6 years ago by
| Status: | reopened → assigned |
|---|
comment:11 Changed 6 years ago by
Bill approved the PR, I committed, but the system assigned it to my git email instead of my trac user name, so I fixed it. I'm also in the process of backporting.
comment:12 Changed 6 years ago by
the system assigned it to my git email instead of my trac user name, so I fixed it
What does this even mean? What are you “fixing”?
comment:13 follow-up: 14 Changed 6 years ago by
At the risk of being reactive, if you mean you are trying to change the email address on the commit to be something else: you can’t. You already pushed the commit. It is done and cannot be changed. Do not attempt a force push to “fix” it or you will lose push permissions.
comment:14 follow-up: 19 Changed 6 years ago by
Replying to csnover:
What does this even mean? What are you “fixing”?
Every time I commit, Git always sets the Trac ticket's "Owned By" field to my Git id. I would prefer that it left the field as my Trac id.
Replying to csnover:
At the risk of being reactive, if you mean you are trying to change the email address on the commit to be something else: you can’t. You already pushed the commit. It is done and cannot be changed. Do not attempt a force push to “fix” it or you will lose push permissions.
I am aware of the dangers of rebasing repos that other people use and that has not happened here.
comment:15 Changed 6 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
comment:17 Changed 6 years ago by
Though I have seen it happen in the past, the owner never changed on this ticket, so that confused me. Thank you for clarifying.
comment:19 Changed 6 years ago by
Replying to haysmark:
Every time I commit, Git always sets the Trac ticket's "Owned By" field to my Git id. I would prefer that it left the field as my Trac id.
From what I've seen, that only happens when there's no owner previously set, and then it shows a message about the owner being changed, for example see https://bugs.dojotoolkit.org/ticket/17418#comment:4). According to the history of this ticket, there's only one place where it says "owner set to", in comment:2. Looks like neither comment:7 nor comment:9 changed the owner, otherwise those comments would have "owner changed" messages.
comment:20 follow-up: 21 Changed 6 years ago by
i think calling these in startup is not a complete solution. isn't it possible to add an item/option after startup and won't those new items possibly have the wrong values? maybe those values could be passed to new items when they are constructed via _addOptionItem? (https://github.com/dojo/dojox/commit/c58ca9ecbb439aa2a170b683995d646a12ecd3ee#commitcomment-4233729)
my suggestions are just based on a cursory look at the code - maybe there's something i've missed.
comment:21 Changed 6 years ago by
Replying to neonstalwart:
i think calling these in
startupis not a complete solution. isn't it possible to add an item/option afterstartupand won't those new items possibly have the wrong values? maybe those values could be passed to new items when they are constructed via_addOptionItem? (https://github.com/dojo/dojox/commit/c58ca9ecbb439aa2a170b683995d646a12ecd3ee#commitcomment-4233729)
Apparently it is much worse that you thought: if you add a new item, all of the old items are deleted and reconstructed, so it gives the appearance of resetting the disabled state of every item. I agree that the logic needs to happen earlier.
Test case with disabled select in the bottom right.