Describe the bug
In Richeditbox and Textbox when scrollbar is in focus the mouse pointer is still an ibeam instead of an arrow.
Steps to reproduce the bug
Implement standard Richeditbox and Textbox with scrolling support in your app.
Expected behavior
When scroll bar is on focus the pointer should change to an arrow, and when content is in focus pointer would change back to ibeam.
Version Info
NuGet package version: Microsoft.UI.Xaml 2.3.200213001
| Windows 10 version | Saw the problem? |
| :--------------------------------- | :-------------------- |
| Insider Build (19564) | Yes |
| November 2019 Update (18363) | Yes |
| May 2019 Update (18362) | Yes |
| October 2018 Update (17763) | Yes |
| April 2018 Update (17134) | Yes |
| Fall Creators Update (16299) | Yes |
| Creators Update (15063) | Yes |
| Device form factor | Saw the problem? |
| :-------------------- | :------------------- |
| Desktop | Yes |
| Mobile | |
| Xbox | |
| Surface Hub | |
| IoT | |
Additional context
@soumyamahunt I'm unable to reproduce this so far with some quick testing. I'm seeing the I-beam transition off and on as I move around. Can you please provide more detail about how your TextBox and scroller are configured? Provide some sample markup, and screen captures are always nice.
@soumyamahunt I'm unable to reproduce this so far with some quick testing. I'm seeing the I-beam transition off and on as I move around. Can you please provide more detail about how your TextBox and scroller are configured? Provide some sample markup, and screen captures are always nice.
The issue I am describing is when the scroll bar is focused (dragged up and down or just hovered over) the pointer doesn't transition from I-beam to arrow. Here is a comparison of a sample Richeditbox control and default notepad app:
Notice how the pointer transitions when scroll bar focused in notepad.
@soumyamahunt thanks for the visual, that's _super_ helpful! Based on your original description I was indeed trying something different from what you were describing. But after seeing that I've got this reproducing just fine, thank you! (I had been hosting it in a scroller, not just relying on RichEditBox's scroller, aka I was overcomplicating it :))
@ddalp Are you aware of any issues with how RichEditBox sets the cursor with regards to the scrolling?
@chrisglein This is an old OS bug we chose not to fix years ago. I remember the issue is that the caret type determined by TextBoxView part of the RichEditBox which is I-beam type. We should add logic to reset the cursor type by calling SetCursor when point exits the TextBoxView.
@chrisglein This is an old OS bug we chose not to fix years ago. I remember the issue is that the caret type determined by TextBoxView part of the RichEditBox which is I-beam type. We should add logic to reset the cursor type by calling SetCursor when point exits the TextBoxView.
I tried using ScrollViwer Extensions from Windows Community Toolkit to apply scroll with mouse middle click. But the pointer type doesn't change when pointer is over RichEditBox control. May be adding ability to change cursor type to anything would be better instead of restricting to I-beam.
Hi,
Is there a timeline when this issue is planned to be fixed?
This reduces the user experience for certain UWP text editors e.g. Notepads.
This issue exists in Windows 10 1909, Build 18363.836.
Adding to what @SuhasSrinivasan said. Will this bug be fixed any time soon? For end users, it's displeasing to have this visual glitch when using notepad-like apps.
Most helpful comment
@chrisglein This is an old OS bug we chose not to fix years ago. I remember the issue is that the caret type determined by TextBoxView part of the RichEditBox which is I-beam type. We should add logic to reset the cursor type by calling SetCursor when point exits the TextBoxView.