More conservatively add EditableText support to UIA objects#18404
Conversation
|
Thanks. I think the impact is the same, but I'm wondering whether it makes more sense to restrict when we use EditableText, rather than restricting when we use UIATextInfo. That is, I think it is wrong to say "this object is editable text" when it clearly isn't. On the other hand, the TextInfo isn't a statement of behaviour; it's a statement of support. It isn't saying "this is editable"; it's saying "this supports querying text", which it does. We might choose not to use it, but it still supports it. Keeping the TextInfo means that something could use makeTextInfo if it wanted to. It's then a higher layer decision to choose whether to use it or not. I still wonder whether this is a risky change given that we're touching things that have been thus for 16 years. :) |
|
Reducing when we use EditableText is also probably slightly less risky than altering TextInfo. |
|
Makes sense to me. I reworked this pr accordingly. |
Link to issue number:
Fixes #18399
Fixup regression caused by #18271
Summary of the issue:
Since #18271, object navigation might cause errors with braille in XAML static text controls.
Description of user facing changes:
No errors, working braille.
Description of developer facing changes:
N/a
Description of development approach:
Be more conservative in applying an EditableText overlay class to UIA objects. Before this change, objects only needed to have UIATextInfo, implicitly meaning that it ought to have a text pattern. With this, we only add EditableText if either:
a. The object has navigable text; or
b. The objects text pattern reports that selection is supported.
Testing strategy:
Tested str from #18399
Known issues with pull request:
I can't think of any reason why this is too conservative. May be in severely broken TextPattern implementations that don't implement
SupportedTextSelection. I only just discovered this property.Code Review Checklist:
@coderabbitai summary