Should we also not build the system wide buttons if the text selection is invalid?

This check was inspired by the implementation of accessors such as cutEnabled, copyEnabled, etc. See

Those accessors are called in EditablTestState.contextMenuButtonItems just before the call to _textProcessingActionButtonItems I added. Because this is meant to build the text selection toolbar, it would make sense that a check to TextSelection.isValid is done somewhere before.

I did not spot an obvious place where such a check is done so I have updated the PR to add this check on the line you commented.

For my understanding what does an app developer expect when the system wide button is used on static text/readOnly? And in what cases would processedText be null?

If the buttons are expected to do nothing on static text, do they still show up when used on static text despite that?

They are two types of activities registered to Intent.ACTION_PROCESS_TEXT:

• some will use the selected text (selectedText variable in this code) to open their UI and will display a result (for instance, on my phone I have one activity that will read the text loudly, I also have Google Translate and Deepl that will show the translation using their own panels). Such activities does not return a result (processedText will be null in this case).
• some will use the selected text to return a modified version (on my phone I have an app called 'Encrypt Text' that does that (it opens an UI where I can ask to see the encrypted text and a button to replace the current selection with this encrypted text). Such activities returns a result (processedText won't be null in this case and we use it to replace the current selection).

I have upated the PR with a comment to explain that is expected that some activities does not return a modified text.