SplitButton doesn't behave as split button using touch

[GeertvanHorrik]

Describe the bug

SplitButton doesn't behave as split button using touch.

Steps to reproduce the bug

1. Create a split button with a default command and drop down (e.g. with content 'Play')
2. Try clicking the "button" part with the mouse => works
3. Try tapping the "button" part with touch => shows dropdown

Expected behavior

Since a default command is bound to the button, I don't want to repeat myself inside the dropdown for touch (otherwise I would have used the DropDownButton). I would expect the SplitButton to be invoking the command when tapping the button part.

Screenshots

Using mouse:

Using touch:

Version Info

All windows versions (Windows 10 Mobile, and the 1809 update on a surface tablet)

NuGet package version:

<PackageReference Include="Microsoft.UI.Xaml">
  <Version>2.0.181018003.1</Version>
</PackageReference>

Windows 10 version:

• Insider Build (xxxxx)
• October 2018 Update (17763)
• April 2018 Update (17134)
• Fall Creators Update (16299)
• Creators Update (15063)
• Anniversary Update (14393)

Device form factor:

• Desktop
• Mobile
• Xbox
• Surface Hub
• IoT

Additional context

[jevansaks]

This behavior is intentional because the chevron button is smaller than the recommended touch target size and would be too difficult to reliably hit, so touch tap always expands. I'll let @adambarlow discuss whether in practice users like this behavior.

[adambarlow]

Jevan is correct, this was by design in terms of our UX philosophy and guidelines on touch target sizes. We have been having a few conversations about this and this while we haven't had negative end user feedback yet, we have had feedback from teams utilizing the control that it should work like mouse for touch. I am personally open to this change, but would like to verify it can be used reliably before making the change.

[GeertvanHorrik]

Then shouldn't it be mentioned in the remarks of the docs? And I think it's still a design issue, because in this case it's not a split button at all (and I need to repeat myself in order to get the regular button behavior, it's actually not working as intended on touch devices).

[mdtauk]

If you can detect if the control is on a touch capable display, then it could add padding to extend the width of the chevron button?

[adambarlow]

@GeertvanHorrik
If it's not working correctly as a button then that would be a bug. Please let us know how it's misbehaving specifically.

@mdtauk
A lot of devices have touch monitors that are primarily driven by mouse / keyboard. We would prefer to design our controls to look one way on all devices to ensure consistency of design, while also ensuring they work for all input modalities.

I think this is worth exploring further and would of course prefer for touch users to have the ability to have a split-button with two touch targets. We'll take a look at the sizing and reliability.

[mdtauk]

@mdtauk
A lot of devices have touch monitors that are primarily driven by mouse / keyboard. We would prefer to design our controls to look one way on all devices to ensure consistency of design, while also ensuring they work for all input modalities.

I think this is worth exploring further and would of course prefer for touch users to have the ability to have a split-button with two touch targets. We'll take a look at the sizing and reliability.

There are some controls, such as ComboBox flyouts, and Context Menus that do increase their item sizes when called via a touch input. But it is true that the default state of a control tends to be consistent in all modes.

I would like to put forward a 32 x 32 chevron button, with a vertical separator alongside the standard button. That separator would then give some confidence to people using touch input.

[GeertvanHorrik]

If it's not working correctly as a button then that would be a bug. Please let us know how it's misbehaving specifically.

Whenever you implement a command on the button itself (SplitButton.Command), then that will never be invokable. So you must repeat yourself in the flyout in order to actually allow the (most important) command to be executable.

I think it's a UX design issue, that can be considered a bug in the apps using this button of the devs are not aware of this.

[lukasf]

I agree that the current behavior feels broken on touch. There could be a property to always open the flyout on touch, so people could opt-in into the current behavior. But the default should be to execute the command.

[mdtauk]

#1207 Mentioning this related Issue, The Toggle Split Button doesn't work with Touch

[Dylanshapiro]

I have a client that is reporting this as a bug. will this ever get fixed?

[sonnemaf]

The SplitButton is now for me totally useless. Please reconsider this UX philosophy. If I would have wanted this behavior, I would have used a DropDownButton.

[WillPittenger]

How about a setting somewhere?

[sonnemaf]

How about a setting somewhere?

I would use a property for that. For example, a TouchMode property which is an Enum (values 'Select', 'Popup').

<SplitButton TouchMode="Select">
    <StackPanel Orientation="Horizontal" Spacing="8">
        <FontIcon FontFamily="{ThemeResource SymbolThemeFontFamily}" Glyph="&#xE75C;" />
        <TextBlock Text="Erase" />
    </StackPanel>
    <SplitButton.Flyout>
        <MenuFlyout Placement="Bottom">
            <MenuFlyoutItem Text="Erase">
                <MenuFlyoutItem.Icon>
                    <FontIcon FontFamily="{ThemeResource SymbolThemeFontFamily}" Glyph="&#xE75C;" />
                </MenuFlyoutItem.Icon>
            </MenuFlyoutItem>
            <MenuFlyoutItem Text="Mark as guess">
                <MenuFlyoutItem.Icon>
                    <FontIcon FontFamily="{ThemeResource SymbolThemeFontFamily}" Glyph="&#xE11B;" />
                </MenuFlyoutItem.Icon>
            </MenuFlyoutItem>
            <MenuFlyoutItem Text="Mark as certain">
                <MenuFlyoutItem.Icon>
                    <FontIcon FontFamily="{ThemeResource SymbolThemeFontFamily}" Glyph="&#xE001;" />
                </MenuFlyoutItem.Icon>
            </MenuFlyoutItem>
        </MenuFlyout>
    </SplitButton.Flyout>
</SplitButton>

[WillPittenger]

I was referring to a user preference. Something that would affect the accuracy required.

[simon-knuth]

This decision really doesn't make sense anymore, especially since Windows 11 launched. The shell features many buttons with much smaller touch targets (and no tolerance), yet the SplitButton doesn't trust the user's touch input.

[github-actions]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[mdtauk]

This is still an issue with the control by default I believe.

[Dylanshapiro]

is there a way to override the class and fix this issue? if so could someone show an example

[sonnemaf]

I didn't find a solution for it. I just stopped using it.

[bkudiess]

This issue was fixed internally and will be available soon :)

[Pinguin2001]

@bkudiess Is this issue going to be fixed on the WUX side as well/backported to all currently supported builds? I have revived a bug report from a Surface Pro X user running 26100 about this exact issue on an app of mine