[UIA] Support querying plain text in documents
Categories
(Core :: Disability Access APIs, task)
Tracking
()
People
(Reporter: Jamie, Unassigned)
References
(Blocks 1 open bug)
Details
Bug 1901456 implements support for querying text in text boxes. Clients also need to be able to query text anywhere in the document. This will involve supporting ITextProvider on documents, as well as teaching our ITextRangeProvider implementation not to restrict to text boxes when the range was constructed from the document.
|
Reporter | |
Comment 1•2 years ago
|
||
When working on this, a test needs to be added for SupportedTextSelection with CSS user-select: none.
|
|
Reporter | |
Comment 2•2 years ago
|
||
(In reply to James Teh [:Jamie] from comment #0)
as well as teaching our ITextRangeProvider implementation not to restrict to text boxes when the range was constructed from the document.
It turns out that I'm wrong about this. The UIA documentation on this is somewhat confusing and inconsistent. It says this:
Objects backed by the same text store as their container are referred to as "compatible" embedded objects. These objects can be TextPattern objects themselves and, in this case, their text ranges are comparable to text ranges obtained from their container. This enables the providers to expose client information about the individual TextPattern objects as if they were one, large text provider.
But later, it says this:
For embedded TextPattern objects, the Document unit only recognizes the content contained within that element.
If the ranges are the same, that's not possible, since otherwise there would be confusion about what ExpandToEnclosingUnit(TextUnit_Document) means. If the range moved outside of its original element and then back inside, should it expand to the element or the entire document?
It seems both Microsoft Word and Edge implement this such that the Document unit is the entire document, regardless of which element the range was retrieved from. So I think we should do the same. I don't really agree with this, but apparently this is what Microsoft wants.
On the flip side, this makes our code simpler and actually means we can just roll this into bug 1901456.
Description
•