Prevent conditionally revealed questions getting out of sync when multiple sets of radios and checkboxes contain inputs with the same name #2255
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Should we include this in 3.13.0 or hold this and merge after the release has gone out? We have 'frozen' the release, but arguably these are things that could have been fixed as part of #2151. Equally, these are existing bugs that are unlikely to come up in most contexts. |
I vote for holding! |
|
Hmm, testing the new examples with VoiceOver in Safari I found that the |
lfdebrux
reviewed
Jun 22, 2021
lfdebrux
reviewed
Jun 22, 2021
| var $target = document.querySelector('#' + $input.getAttribute('aria-controls')) | ||
| var $target = document.getElementById($input.getAttribute('aria-controls')) |
|
I think it might be good to have tests for this behaviour to catch possible future regressions; something like 32f116d for example? |
|
I've realised that the (necessary) change from Attached to the 4.0 milestone. |
lfdebrux
force-pushed
the
radio-checkboxes-tweaks
branch
from
32f116d
to
7c3dd77
Compare
lfdebrux
force-pushed
the
radio-checkboxes-tweaks
branch
from
7c3dd77
to
6ad421d
Compare
|
@36degrees I've added more tests in 6ad421d, I think covering everything this PR fixes. I have run these tests before the fixes and they fail as expected, so I think they should make good regression tests. Feel free to leave comments/suggestions on them! |
45 tasks
vanitabarrett
approved these changes
Sep 27, 2021
36degrees
changed the title
36degrees
changed the title
36degrees
force-pushed
the
radio-checkboxes-tweaks
branch
from
6ad421d
to
b4b8541
Compare
govuk-design-system-ci
temporarily deployed
to
govuk-frontend-pr-2255
We have an open issue to provide examples of grouping radios and checkboxes under headings (#1079). Whilst we don’t provide any guidance on this at the minute, we’ve previously suggested that users can achieve this by making multiple calls to the `govukCheckboxes` macro and grouping them together inside a single call to `govukFieldset`. However, this means that each ‘set’ of checkboxes is inside its own module, which can cause issues with things like conditional reveals. Add an example of this to the review app, so that we can test that everything works as expected.
Rather than calling `this.syncAllConditionalReveals`, which only syncs conditional reveals on checkboxes within the same module, sync every conditional reveal with the same name and form owner during the the existing loop. When syncing each conditional reveal, we also need to look for the targeted element across the entire document, as we might be syncing a conditional reveal outside of the current module. We can also simplify the lookup by using document.getElementById rather than using querySelector which requires us to manually prepend the hash to get an ID selector.
This matches a change previously made to the checkboxes component in 7e746b4. If you use two separate calls to the macro with the same name, but one of them does not contain any radios with conditional reaveals, then checking a radio in that list would not hide a conditional reveal in the other list, as the module has not been initialised so no `eventListener` has been set up. Always initialise the javascript for every set of radios which solves this issue.
Use document.getElementById rather than document.querySelector which requires us to manually prepend the hash to get an ID selector.
Adds tests for JavaScript behaviours we want to work across separate groups of radios or checkboxes with the same `name`, specifically: - conditional reveals - 'none of the above' checkbox
36degrees
force-pushed
the
radio-checkboxes-tweaks
branch
from
b4b8541
to
8d9ce98
Compare
govuk-design-system-ci
temporarily deployed
to
govuk-frontend-pr-2255
|
For some reason the GitHub Actions have not been triggered on the latest commit. Closing and re-opening to try and force them to run… |
36degrees
changed the title
Merged
andymantell
added a commit
to surevine/govuk-react-jsx
that referenced
this pull request
Jan 29, 2022
data-module attribute now always present. See alphagov/govuk-frontend#2255 See also alphagov/govuk-frontend#2516
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We have an open issue to provide examples of grouping radios and checkboxes under headings.
Whilst we don’t provide any guidance on this at the minute, we’ve previously suggested that users can achieve this by making multiple calls to the
govukCheckboxesmacro and grouping them together inside a single call togovukFieldset. However, this means that each ‘set’ of checkboxes is inside its own module, which can cause issues with things like conditional reveals.Add an example of this to the review app, so that we can test that everything works as expected, and fix a few issues identified that can leave conditional reveals 'out of sync' with their controls in this context.
See individual commits for details.
Details of breaking change
Although technically this is a breaking change, it's the 'same' breaking change as in #2370. So I suggest we just include this in the list of 'Fixes'.