You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Android] Consider showing an arrow cursor when hovering over buttons with mouse #170296
CC'ing the framework to see if there's any opposition to this proposal, e.g. philosophically, users are responsible for using MouseRegions themselves to change the cursor as they wish to abide by Android's quality standards.
(This is part of b/366229477)
To achieve Tier 1 large screen compatibility, different cursors should appear as users interact different UI elements; see the Large screen app quality docs. As part of this, an arrow cursor* should be shown on all buttons (this includes TextButton, IconButton, FloatingActionButton, ElevatedButton, DropdownButton, PopupMenuButton)**--this is explicitly stated in go/support_touchpad. So, we should consider ensuring an arrow pointer is used when buttons are hovered over.
One option for implementing this functionality is by using a MouseRegion.
*I believe this maps to SystemMouseCursors.basic, though see details in go/support_touchpad because that arrow has a Material-looking style, which should map to PointerIcon.TYPE_ARROW.
**Technically, buttons made from pure text should be excluded, but this sort of button is not supported by Flutter out of the box (a developer would just use make some Text clickable). So, I think it's fair to assume a developer can make sure a desirable cursor is used there themselves.
@framework team one of the questions we are hoping to figure out is what layer of the stack should this work happen. For example should the android team wrap all the widget we control with a mouse region or should we modify the definition of button to have a mouse region by default or something else?
I do think this issue hits on a larger question of what the Material library should do to meet Android's standards in general because, for instance, I have the same sort of question with scrolling; Android recommends showing a scrollbar for scrolling content, but we seem to require Scrollbar to ensure one is shown for ScrollViews. That seems parallel to needing MouseRegion to show a particular cursor that Android recommends.
Relevant part of the styleguide: "Avoid the lowest common denominator... [Flutter should aim] to be the best way to develop for each platform individually."
Ideally Flutter's buttons should work like they do on the native platform out of the box and show the correct cursor by default. Otherwise we would have to document that devs should wrap their buttons in MouseRegion, which is a bad developer experience, and would result in lots of people missing this point and launching Flutter apps with poor mouse support.
Some caveats I can think of though:
Users that want to customize or remove this behavior should be able to do so.
We should be wary of breaking existing users. How will this change affect people that are already wrapping their buttons in MouseRegion?
Do other platforms also show a mouse cursor like this? It looks like the Cupertino library already wraps its buttons in MouseRegions by default.
So tl;dr I think it does make sense to put MouseRegion in ButtonStyleButton, but check how other native platforms behave and watch out for breaking changes.
So tl;dr I think it does make sense to put MouseRegion in ButtonStyleButton, but check how other native platforms behave and watch out for breaking changes.
changed the title [-][Android] Consider showing an arrow cursor when hovering over buttons[/-][+][Android] Consider showing an arrow cursor when hovering over buttons with mouse[/+]on Jun 25, 2025
Just renamed issue to reflect this, but the correct (arrow) cursor is already used by default with a trackpad from my testing. The issue appears with a mouse specifically.
Thanks @/justinmc for the notes! Seems like ButtonStyleButtons are how cursors are ultimately determined. I'll need to play around with how to factor in the styles set at the <Type>Button level and how to make sure the cursor is resolved correctly in the InkWell.
https://developer.apple.com/design/human-interface-guidelines/pointing-devices seems like a pretty good overview on pointers for the Apple platforms. It notes that for iPadOS, the circle cursor is pretty much used across the board (I will verify this). For MacOS, there's more of an array of supported pointers like Android. As far as I can tell based on #Pointers and the arrow docs that the pointer arrow would be used over buttons. In my experience in, for example, Gmail, I see pointingHand, though, so I'm a bit confused.
I would like to compare the current behavior of Flutter Material buttons on Apple platforms to this expected behavior.
Still working on verifying the behavior of Cupertino, Material buttons on Flutter iOS, but I've gotten some draft changes working for Material buttons on Android, and I've come up with the following comprehensive (I believe) list of questions I still need to resolve:
1. [WIP] How do Cupertino, Material buttons behave on iOS? Do I need to modify my PR to make sure the cursors on iOS are not impacted?
I will note that I already see that on Android, Cupertino buttons use the arrow cursor like I am trying to get Material buttons to use at least on Android.
2. Should Material buttons behave like it's running on Android on non-Android devices? Otherwise, we may need to gate my changes based on target platform.
I may need to look through the style guide or get framework input on this as this is a higher level design philosophy question I don't know the answer to.
3. Which buttons need a cursor parameter added to/modified cursor parameters to ensure customization is possible for those wishing to stick with the current default click cursor instead of the new arrow default?
As of my current understanding, there will be two classes of users impacted by this change: (1) those who have a customized cursor already (via parameters provided by a particular button) or (2) those who just use the default cursor.
Those falling in class (1) will not be broken by my change. Note that I explicitly excluded those using a wrapper MouseRegion to change the cursor of a button because this is not possible based on my testing; if you do this, the default cursor is still preferred over the cursor set in the outer MouseRegion. Also note that not all buttons include parameters to change the cursor, so we know with 100% certainty that users of some buttons must fall in class (2).
Those falling in class (2) will be broken by my change. To avoid this, we will probably need to (1) add a parameter to the buttons that don't include one to modify the cursor and (2) change the default for those with pre-existing and new cursor parameters to the arrow. I need to double check what breaking change policies that I need to follow before changing the default cursor.
Just fyi that I've gotten these questions answered :) 3 is in progress and for 1/2 I chatted with @MitchellGoodwin about to come to some conclusions. Currently working on some higher priority items, but I'll update this issue when I get back to it.
Okay circling back around to this since my PR is about ready 😄 As I mentioned, chatted with @/MitchellGoodwin and these are the conclusions we came to.
1. How do Cupertino, Material buttons behave on iOS? Do I need to modify my PR to make sure the cursors on iOS are not impacted?
Cupertino widgets should expect only to run on iOS as there's no guidance for how it should behave on Android. For my PR, this means it is ok to modify Material widgets across the board and I'll leave Cupertino alone. Cupertino behavior matches the change on Android anyway so the Material widget changes shouldn't a big deal to iOS users.
2. Should Material buttons behave like it's running on Android on non-Android devices? Otherwise, we may need to gate my changes based on target platform.
The guidance provided to me makes it seem like the answer is yes except on web, which sticks to the click arrow cursor. So, my changes will be gated by a kIsWeb check.
3. Which buttons need a cursor parameter added to/modified cursor parameters to ensure customization is possible for those wishing to stick with the current default click cursor instead of the new arrow default?
I don't have the exact list, but I went through all of the buttons and made sure they had a customizable mouse cursor (added one if not) and added tests.
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
Activity
reidbaker commentedon Jun 10, 2025
@framework team one of the questions we are hoping to figure out is what layer of the stack should this work happen. For example should the android team wrap all the widget we control with a mouse region or should we modify the definition of button to have a mouse region by default or something else?
camsim99 commentedon Jun 12, 2025
I do think this issue hits on a larger question of what the Material library should do to meet Android's standards in general because, for instance, I have the same sort of question with scrolling; Android recommends showing a scrollbar for scrolling content, but we seem to require
Scrollbarto ensure one is shown forScrollViews. That seems parallel to needingMouseRegionto show a particular cursor that Android recommends.Edit: Filed #170540 for this.
justinmc commentedon Jun 13, 2025
Relevant part of the styleguide: "Avoid the lowest common denominator... [Flutter should aim] to be the best way to develop for each platform individually."
Ideally Flutter's buttons should work like they do on the native platform out of the box and show the correct cursor by default. Otherwise we would have to document that devs should wrap their buttons in MouseRegion, which is a bad developer experience, and would result in lots of people missing this point and launching Flutter apps with poor mouse support.
Some caveats I can think of though:
So tl;dr I think it does make sense to put MouseRegion in ButtonStyleButton, but check how other native platforms behave and watch out for breaking changes.
Piinks commentedon Jun 18, 2025
++
3 remaining items
[-][Android] Consider showing an arrow cursor when hovering over buttons[/-][+][Android] Consider showing an arrow cursor when hovering over buttons with mouse[/+]camsim99 commentedon Jun 25, 2025
Just renamed issue to reflect this, but the correct (arrow) cursor is already used by default with a trackpad from my testing. The issue appears with a mouse specifically.
camsim99 commentedon Jun 25, 2025
Thanks @/justinmc for the notes! Seems like
ButtonStyleButtons are how cursors are ultimately determined. I'll need to play around with how to factor in the styles set at the<Type>Buttonlevel and how to make sure the cursor is resolved correctly in theInkWell.camsim99 commentedon Jul 1, 2025
https://developer.apple.com/design/human-interface-guidelines/pointing-devices seems like a pretty good overview on pointers for the Apple platforms. It notes that for iPadOS, the circle cursor is pretty much used across the board (I will verify this). For MacOS, there's more of an array of supported pointers like Android. As far as I can tell based on #Pointers and the
arrowdocs that the pointer arrow would be used over buttons. In my experience in, for example, Gmail, I seepointingHand, though, so I'm a bit confused.I would like to compare the current behavior of Flutter Material buttons on Apple platforms to this expected behavior.
camsim99 commentedon Jul 9, 2025
Still working on verifying the behavior of Cupertino, Material buttons on Flutter iOS, but I've gotten some draft changes working for Material buttons on Android, and I've come up with the following comprehensive (I believe) list of questions I still need to resolve:
1. [WIP] How do Cupertino, Material buttons behave on iOS? Do I need to modify my PR to make sure the cursors on iOS are not impacted?
I will note that I already see that on Android, Cupertino buttons use the arrow cursor like I am trying to get Material buttons to use at least on Android.
2. Should Material buttons behave like it's running on Android on non-Android devices? Otherwise, we may need to gate my changes based on target platform.
I may need to look through the style guide or get framework input on this as this is a higher level design philosophy question I don't know the answer to.
3. Which buttons need a cursor parameter added to/modified cursor parameters to ensure customization is possible for those wishing to stick with the current default click cursor instead of the new arrow default?
As of my current understanding, there will be two classes of users impacted by this change: (1) those who have a customized cursor already (via parameters provided by a particular button) or (2) those who just use the default cursor.
Those falling in class (1) will not be broken by my change. Note that I explicitly excluded those using a wrapper
MouseRegionto change the cursor of a button because this is not possible based on my testing; if you do this, the default cursor is still preferred over the cursor set in the outerMouseRegion. Also note that not all buttons include parameters to change the cursor, so we know with 100% certainty that users of some buttons must fall in class (2).Those falling in class (2) will be broken by my change. To avoid this, we will probably need to (1) add a parameter to the buttons that don't include one to modify the cursor and (2) change the default for those with pre-existing and new cursor parameters to the arrow. I need to double check what breaking change policies that I need to follow before changing the default cursor.
camsim99 commentedon Aug 12, 2025
Just fyi that I've gotten these questions answered :) 3 is in progress and for 1/2 I chatted with @MitchellGoodwin about to come to some conclusions. Currently working on some higher priority items, but I'll update this issue when I get back to it.
camsim99 commentedon Sep 15, 2025
Okay circling back around to this since my PR is about ready 😄 As I mentioned, chatted with @/MitchellGoodwin and these are the conclusions we came to.
Cupertino widgets should expect only to run on iOS as there's no guidance for how it should behave on Android. For my PR, this means it is ok to modify Material widgets across the board and I'll leave Cupertino alone. Cupertino behavior matches the change on Android anyway so the Material widget changes shouldn't a big deal to iOS users.
The guidance provided to me makes it seem like the answer is yes except on web, which sticks to the click arrow cursor. So, my changes will be gated by a
kIsWebcheck.I don't have the exact list, but I went through all of the buttons and made sure they had a customizable mouse cursor (added one if not) and added tests.
[Material] Change default mouse cursor of buttons to basic arrow inst…
github-actions commentedon Nov 7, 2025
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.[Material] Change default mouse cursor of buttons to basic arrow inst…
[Material] Change default mouse cursor of buttons to basic arrow inst…
[Material] Change default mouse cursor of buttons to basic arrow inst…