When injecting a custom selection check renderer into a DetailsList and using Fabric's own Checkbox component inside it, clicking on the checkbox itself does not update the selection. Clicking on the area inside the cell surrounding it does update the selection correctly. Using a native checkbox updates the selection just fine as well.
https://codepen.io/nimelrian/pen/aXMxvR?editors=1010
This renders two DetailsLists, one with Fabric's checkboxes, the other with native checkboxes. Both lists share the same selection instance.
Clicking a Fabric checkbox does not update the selection.
Clicking the cell of a Fabric checkbox updates the selection.
Clicking a native checkbox updates the selection.
Clicking the cell of a native checkbox updates the selection.
Clicking a Fabric checkbox updates the selection.
Clicking the cell of a Fabric checkbox updates the selection.
Clicking a native checkbox updates the selection.
Clicking the cell of a native checkbox updates the selection.
Are you willing to submit a PR to fix?
I already took a look into the source code of the Checkbox component but couldn't find anything which may cause the click not to be handled. If someone else has an idea what the issue may be, I could take another look.
Requested priority: High
Hey @Nimelrian, I think what is happening here is that the List's row does not know that the state changed and therefore it is not re-rendered until another action occurs which causes a re-render such as: a row click, window resize, etc.
You may be able to workaround this by forcing the row / list be updated (re-rendered). As for the proper fix, I'm unsure at this time. However, I'd be willing to review a PR which solved it.
If only the row wouldn't update, the selection count would still update. Something is causing the whole selection event to be swallowed when clicking the Fabric Checkbox.
Ok, so I just went through with the debugger. It looks like when clicking the Fabric Checkbox, SelectionZone::_onClick gets called twice, which selects the row and then deselects it immediately. This definitely seems to be some kind of bug.
It looks like this is an issue of different onClick handlers of the Checkbox component not preventing Event propagation. The same event runs into the Selection::_onClick handler twice. Once targeting the "checkbox" div inside the checkbox, then again targeting the input element.
The issue seems to be caused by the input element being positioned over the checkbox div and being hidden via styling.
This is definitely something which cannot be fixed from the userland side.
@KevinTCoughlin seems like they are not able to work around this issue with just forcing the row to be updated - do you have any other ideas for how they might go about this? Or is there anything we can do to fix in our DetailsList?
@KevinTCoughlin seems like they are not able to work around this issue with just forcing the row to be updated - do you have any other ideas for how they might go about this? Or is there anything we can do to fix in our DetailsList?
@aneeshack4, if this is a supported scenario, fixing the problem mentioned below seems to be the path forward given the debugging done by @Nimelrian:
The same event runs into the
Selection::_onClickhandler twice. Once targeting the "checkbox" div inside the checkbox, then again targeting the input element.
The issue seems to be caused by the input element being positioned over the checkbox div and being hidden via styling.
Before doing so, we should understand what scenario @Nimelrian is trying to support that working with the default DetailsRowCheck does not provide. @Nimelrian can you clarify why you need to use Checkbox?
Sure. Our UI designer, UX designer, and management isn't happy with the circular checkmarks of the DetailsRowCheck in multi-selection lists since they raise the thought with users that those checkmarks are actually radio boxes, due to the circular shape.
So I was asked to replace them with regular checkboxes, and to keep it in line with the rest of the UI we wanted to use the regular Fabric checkbox which we use elsewhere as well.
@Nimelrian I'd encourage you to submit a PR for this if you're comfortable since it seems like you have an idea of the solution and have context of the problem. It's not especially a scenario that we support that often so at this time, we won't be able to do a PR for this.
I tried fiddling around with it but came up without a solution. My first thought was that the event propagation wasn't stopped, but it actually is. No idea why the event is fired again after that. I'll probably replace the regular Checkbox with a dummy one.
Why was this closed? This is an actual bug that is currently unsolved, right?
@cc0rk the author closed it because there was a possible fix on the user's side as you can read in this comment https://github.com/OfficeDev/office-ui-fabric-react/issues/8047#issuecomment-466607271 - if you're reproing this issue, feel free to open another issue with details specific to your case as it looks this issue was quite specific to the author's case.
The root cause is the combination of a few things:
SelectionZone listens to all eventslabel that's tied to an input element is clicked, the browser fires 2 events: one for the label and one for the input. ( https://codepen.io/jdh-msft/pen/NWKxMvN?editors=1111 for a demo)Checkbox UI is a check icon inside of a label that triggers a hidden input, meaning 2 events are fired ever time.A workaround is as follows: render the Checkbox with the following prop:
inputProps={{ 'data-selection-disabled': true } as any}
A full codepen example here: https://codepen.io/jdh-msft/pen/wvwMjxG?editors=1010
Also reopening this issue, as this workaround should not be required for use of a SelectionZone.
I have tried out the workaround and it works for the checkboxes in each row but not for the "select all" checkbox. That checkbox fires 2 events which will select all rows and then de-select right after. I'm not sure how the implementation of the "select all" checkbox differs from each row. Has anyone else seen this issue?