I have a standard Material Design button, as per below
<?xml version="1.0" encoding="utf-8"?>
tools:text="I am a Button"
<style name="PrimaryColoredButton" parent="Widget.AppCompat.Button.Colored">
That behavior is not exclusive to
AppCompatButtons, it seems. It stems from the fact that
Button is a subclass of
TextView, and what's actually triggering that behavior in your case is the
capitalize attribute in your custom style. When this is set
to anything other than , it causes
Editor to become active and respond to long clicks.
In fact, it appears that any attribute setting that causes the
Button to have an input type other than the default will cause this. These attributes include - but are not limited to -
autoText, and, obviously, any
inputType other than
textIsSelectable attribute will cause a little havoc, too, in that the
Button will act like an un-editable
EditText. The cursor and selection handle(s) will appear, along with the editing CAB when appropriate, but no input method, and the
Button becomes un-clickable.
These are clearly not attributes you would normally be setting on a
Button, but this definitely seems like a bug to me, since
Button probably shouldn't, in any way, allow itself to become editable. Indeed, in certain states, pasting text, then shifting focus or clicking causes the
Editor to crash. If this is unintended behavior (the pasting, not the crashing), it's been wrongly implemented for some time, as far as I can tell.
To remedy this, you should remove the
capitalize attribute from your style, and just handle that yourself when you set the text on the
Button. Alternatively, if you don't need to respond to long clicks on your
Buttons, you could set the
longClickable attribute in your style to
Unfortunately, simply setting the (deprecated)
editable attribute to
false doesn't seem to be a fix, if combined with any of the other above-mentioned, problematic attributes.