Skip to content

More conservatively add EditableText support to UIA objects#18404

Merged
seanbudd merged 2 commits into
nvaccess:betafrom
LeonarddeR:fixObjectNavError
Jul 4, 2025
Merged

More conservatively add EditableText support to UIA objects#18404
seanbudd merged 2 commits into
nvaccess:betafrom
LeonarddeR:fixObjectNavError

Conversation

@LeonarddeR
Copy link
Copy Markdown
Collaborator

@LeonarddeR LeonarddeR commented Jul 3, 2025

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:

  • Documentation:
    • Change log entry
    • User Documentation
    • Developer / Technical Documentation
    • Context sensitive help for GUI changes
  • Testing:
    • Unit tests
    • System (end to end) tests
    • Manual testing
  • UX of all users considered:
    • Speech
    • Braille
    • Low Vision
    • Different web browsers
    • Localization in other languages / culture than English
  • API is compatible with existing add-ons.
  • Security precautions taken.

@coderabbitai summary

@LeonarddeR LeonarddeR requested a review from a team as a code owner July 3, 2025 08:01
@LeonarddeR LeonarddeR requested review from jcsteh and seanbudd July 3, 2025 08:01
@jcsteh
Copy link
Copy Markdown
Contributor

jcsteh commented Jul 3, 2025

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. :)

@jcsteh
Copy link
Copy Markdown
Contributor

jcsteh commented Jul 3, 2025

Reducing when we use EditableText is also probably slightly less risky than altering TextInfo.

@LeonarddeR LeonarddeR changed the title Use UIATextInfo more conservatively More conservatively add EditableText support to UIA objects Jul 3, 2025
@LeonarddeR
Copy link
Copy Markdown
Collaborator Author

Makes sense to me. I reworked this pr accordingly.

@seanbudd seanbudd added this to the 2025.2 milestone Jul 4, 2025
@seanbudd seanbudd merged commit 66acf1b into nvaccess:beta Jul 4, 2025
17 of 18 checks passed
@LeonarddeR LeonarddeR deleted the fixObjectNavError branch July 4, 2025 03:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants