Microsoft-ui-xaml: Editable ComboBox: Pointer should be text select

Created on 28 Jun 2019  路  15Comments  路  Source: microsoft/microsoft-ui-xaml

Describe the bug

Pointer should be a text select pointer when hovered over text in an editable ComboBox

Steps to reproduce the bug

Steps to reproduce the behavior:

  1. Open XAML Controls Gallery (pretty easy example)
  2. Navigate to ComboBox
  3. Hover over font size in the editable ComboBox

Expected behavior

The pointer should be a text select pointer (found name via mouse properties) as found in Office and various other apps.

Screenshots

Version Info

NuGet package version:


| Windows 10 version | Saw the problem? |
| :--------------------------------- | :-------------------- |
| Insider Build (xxxxx) | |
| May 2019 Update (18362) | Yes |
| October 2018 Update (17763) | |
| April 2018 Update (17134) | |
| Fall Creators Update (16299) | |
| Creators Update (15063) | |
| Anniversary Update (14393) | |


| Device form factor | Saw the problem? |
| :-------------------- | :------------------- |
| Desktop | Yes |
| Mobile | |
| Xbox | |
| Surface Hub | |
| IoT | |

Additional context

this could totally be an issue on XAML Control Gallery's side so sorry.

area-ComboBox bug needs-winui-3 team-Controls

Most helpful comment

I would vote for a Place Caret on _single click_ option, but a _Double Click_ to Select could be useful.

The Edge/Chrome URL bar, will select all on _single click_, and _another single click_ will place the Caret - but _double clicking_ will select a word or part of the text.

The UWP Text field currently Places the Caret on _Single Click_, Selects a word or part of the text on _Double Click_, and Selects all on a _Triple Click_


Whatever the behaviour chosen, it should apply to future editable controls like NumberBox, Editable Time and Date Pickers, etc

All 15 comments

This does seem to be a control issue, but it could be confusing to show as an I-beam if clicking doesn't place the caret at that location. On the other hand it would be nice to help differentiate between editable and non-editable comboboxes.

I also updated the title to reflect this, I hope that's ok @poopooracoocoo :)

@jevansaks When I hover over the text box in Word it is a text select pointer and selects all of the text when clicked instead of placing a carat.

@jevansaks When I hover over the text box in Word it is a text select pointer and selects all of the text when clicked instead of placing a carat.

OneNote UWP does the same thing. Text cursor, clicking selects all text.

Good observations @poopooracoocoo @mdtauk! Seems like we should just update this control to show the text cursor and not change anything else.

Thanks for jumping on this, @jevansaks!

Hi, @Poopooracoocoo and @mdtauk, I'll be carrying this issue forward. I agree with @jevansaks. We should differentiate between an editable and non-editable ComboBox. However, the "select all text" behavior is an intentional quick-action feature as most often users bring their focus to these controls to fully clear and replace the contents than to edit the existing contents.

I will convert this ticket to a bug so that we can start acting on a fix for the cursor. If the "place caret" behavior is still desired, please let me know and we can kick off a discussion for that and the scope of impact it would need to have, if implemented, to deliver consistency across our control set.

How does this sound to everyone?

I would vote for a Place Caret on _single click_ option, but a _Double Click_ to Select could be useful.

The Edge/Chrome URL bar, will select all on _single click_, and _another single click_ will place the Caret - but _double clicking_ will select a word or part of the text.

The UWP Text field currently Places the Caret on _Single Click_, Selects a word or part of the text on _Double Click_, and Selects all on a _Triple Click_


Whatever the behaviour chosen, it should apply to future editable controls like NumberBox, Editable Time and Date Pickers, etc

Perfect. I see @Poopooracoocoo has updated this issue for the bug path.

Whatever the behaviour chosen, it should apply to future editable controls like NumberBox, Editable Time and Date Pickers, etc.

@mdtauk I hear you and this is something I can get behind. Is this already being covered by any of your design discussions/proposals or should I open up a dedicated issue?

@SavoySchuler I don't think I have included any cursor behaviour in my mockups, but I have covered editable vs non-editable control designs in #899

@mdtauk off topic but do you work at MS?

@mdtauk off topic but do you work at MS?

No :)

@Poopooracoocoo I checked in with @jevansaks, our engineering manager, and the fix to this bug will require WinUI 3.0. @jevansaks labeled as such, so I will unassign myself for now, and we'll be back to this when WinUI 3.0 is here. 馃槃 Thanks for filing this, you're awesome!


I would vote for a Place Caret on _single click_ option, but a _Double Click_ to Select could be useful.

The Edge/Chrome URL bar, will select all on _single click_, and _another single click_ will place the Caret - but _double clicking_ will select a word or part of the text.

The UWP Text field currently Places the Caret on _Single Click_, Selects a word or part of the text on _Double Click_, and Selects all on a _Triple Click_

Whatever the behaviour chosen, it should apply to future editable controls like NumberBox, Editable Time and Date Pickers, etc

@mdtauk, thanks! I have it in my to-do list to add a proposal for this topic. Please feel encourage to beat me to it, but otherwise I will tag you when I have it up!

@SavoySchuler I shall leave that honour to yourself. I was only stating the current behaviours - which one becomes a default is for greater minds than mine.

No need to undersell yourself, @mdtauk! But sounds great, I have it on my list. 馃槉

@SavoySchuler Hey do you have any idea on when you guys will be working on new features for WinUI? WinUI 3.0 development is almost finished I think.

Was this page helpful?
0 / 5 - 0 ratings