Change Details

This is a follow-up to T386273. We discussed in some of our meetings that implementing it exactly as described in the task may or may not be feasible. For now, we will use this task to explore customization, while the original task will follow the default behavior of its OOUI component — which is simply to show an error message if the user selects the "Other" option along with any of the other available options. I’ve created a patch that implements the required behavior, and I’ll attach it to this task for review by the engineering team. Depending on the outcome of the code review, it may or may not be viable, as the current approach is somewhat hacky and could be prone to bugs. This task is meant to validate what level of customization we want to proceed with — or whether we want to customize it at all. We're also open to a smaller customization, such as displaying an error message immediately when the user selects both "Other" and any other option. This would prevent the user from submitting the form until the conflict is resolved.

This is a follow-up to T386273. We discussed in some of our meetings that implementing it exactly as described in the task may or may not be feasible. For now, we will use this task to explore customization, while the original task will follow the default behavior of its OOUI component — which is simply to show an error message if the user selects the "Other" option along with any of the other available options. I’ve created a patch that implements the required behavior, and I’ll attach it to this task for review by the engineering team. Depending on the outcome of the code review, it may or may not be viable, as the current approach is somewhat hacky and could be prone to bugs. This task is meant to validate what level of customization we want to proceed with — or whether we want to customize it at all. We're also open to a smaller customization, such as displaying an error message immediately when the user selects both "Other" and any other option. This would prevent the user from submitting the form until the conflict is resolved. Note that we will want to have this change assessed for accessibility by the design systems team.

This is a follow-up to T386273. We discussed in some of our meetings that implementing it exactly as described in the task may or may not be feasible. For now, we will use this task to explore customization, while the original task will follow the default behavior of its OOUI component — which is simply to show an error message if the user selects the "Other" option along with any of the other available options. I’ve created a patch that implements the required behavior, and I’ll attach it to this task for review by the engineering team. Depending on the outcome of the code review, it may or may not be viable, as the current approach is somewhat hacky and could be prone to bugs. This task is meant to validate what level of customization we want to proceed with — or whether we want to customize it at all. We're also open to a smaller customization, such as displaying an error message immediately when the user selects both "Other" and any other option. This would prevent the user from submitting the form until the conflict is resolved. Note that we will want to have this change assessed for accessibility by the design systems team.