DetailsList: UI bug when selecting many items quickly with selectionMode.single on mobile Safari

[hxltinh]

Environment Information

• Package version(s): 6.138.0
• Browser and OS versions: Mobile Safari (IOS version 12.1.4)

Please provide a reproduction of the bug in a codepen:

codepen

Actual behavior:

When selecting items many time very quickly with selectionMode.single:

Expected behavior:

It should not display grey background on none selected item

Priorities and help requested:

Are you willing to submit a PR to fix? �No

Requested priority: Normal

[aneeshack4]

@hxltinh I just tried to repro this on an iPhone XS with iOS 12.1.4 and it doesn't repro. When I move really quickly touching the different items there's no lag that produces a grey background on an unselected item. What version of iOS are you using? The only thing I can think of that could you get this behavior is perhaps you have started selecting another item but not fully - Apple supports different pressures in touch sensitivity so if you didn't apply full pressure to the newly selected item, the old one stays selected while the new one that you haven't fully selected gets the gray background.

[hxltinh]

@aneeshack4 Please have a look at this gif, hope it helps :)
Edited:
IOS: 12.1.4
device: iPad (6th gen)

[KevinTCoughlin]

@hxltinh I appreciate the report. This is most likely visual lag in the browser repainting given the mobile hardware and current cost of re-rendering items in the DetailsList. We are making optimizations there currently, but I'm unaware of a "quick fix" for this specific bug and hardware combination.

@hxltinh, if you can point to a particularly computationally expensive function resulting in this lag perhaps by using the DevTools "Performance" tab, then we can try to address that issue in particular.

[hxltinh]

@KevinTCoughlin Thanks for your feed back, I already done some test that you mentioned, I need to discuss with my team about the result. May be I'm wrong but I did not see anything strange with the result.

[dzearing]

I believe this is hover related. In IOS if you tap on something it can stick the hover state on a thing, I believe. So even though there is one item selected, the hover state is appearing.

You can see people asking about it here:
https://stackoverflow.com/questions/17233804/how-to-prevent-sticky-hover-effects-for-buttons-on-touch-devices

I would not suggest going with the recommended solution though... hooking up an event hander to touch end of every hoverable entity and remove/adding the node? That's terrible.

This is rather complicated, but perhaps a better approach might be to conditionally show hover state like how we conditionally render focus treatments: if a touch event is detected, disable hovers. if a mouse event is detected, enable. Do it through a global class flag like ms-Fabric--isHoverVisible.

[hxltinh]

@dzearing I think you are right :)

[KevinTCoughlin]

I believe this is hover related. In IOS if you tap on something it can stick the hover state on a thing, I believe. So even though there is one item selected, the hover state is appearing.

You can see people asking about it here:
https://stackoverflow.com/questions/17233804/how-to-prevent-sticky-hover-effects-for-buttons-on-touch-devices

I would not suggest going with the recommended solution though... hooking up an event hander to touch end of every hoverable entity and remove/adding the node? That's terrible.

This is rather complicated, but perhaps a better approach might be to conditionally show hover state like how we conditionally render focus treatments: if a touch event is detected, disable hovers. if a mouse event is detected, enable. Do it through a global class flag like ms-Fabric--isHoverVisible.

TIL. Thanks @dzearing!

[aneeshack4]

Seems like a solution was found that could be done on @hxltinh's end so I'm going to close this - feel free to reopen if it persists/there's follow up.

[hxltinh]

@aneeshack4 If you don't mind, please tell us if this fix will be applied to your repository? because we really don't like applying the work-around solution for this bug.

[aneeshack4]

@hxltinh Ah sorry I thought this was resolved as a fix on your end. I'll see if it's a quick fix I can make while I'm on shield but if it's more involved, it'll need to go onto the backlog. Touch behavior on mobile safari is a pretty limited use case so this is low pri.

[hxltinh]

@aneeshack4 thanks for your feedback, we would like to have it fixed on the repo. We can wait because it's not a serious problem, please take your time :)

[aneeshack4]

Looked into fixing this for a bit and couldn't find anything straightforward so it'll take longer than shield time - putting this into our backlog.

[msft-fluent-ui-bot]

Because this issue has not had activity for over 150 days, we're automatically closing it for house-keeping purposes.

Still require assistance? Please, create a new issue with up-to date details.