1666606 - [meta] Support additional search predicate keys required for content navigation

Status: NEW

(Core :: Disability Access APIs, defect, P3)

Description

[Morgan Reschenberg [:morgan]]

There is a set of AX.*SearchKey's used for content navigation that don't have anything to do with making content appear in rotor. We should support them to allow for better content navigation. From what I can gather, they are as follows:

• AXBlockquoteSameLevelSearchKey
• AXBlockquoteSearchKey
• AXBoldFontSearchKey
• AXDifferentTypeSearchKey
• AXFontChangeSearchKey (Chrome doesn't do this)
• AXFontColorChangeSearchKey (Chrome doesn't do this)
• AXGraphicSearchKey
• AXHeadingLevelXSearchKey (1-6)
• AXHighlightedSearchKey (Chrome doesn't do this)
• AXKeyboardFocusableSearchKey
• AXItalicFontSearchKey
• AXMisspelledWordSearchKey (Chrome doesn't do this)
• AXOutlineSearchKey
• AXPlainTextSearchKey (Chrome doesn't do this)
• AXSameTypeSearchKey
• AXStyleChangeSearchKey (Chrome doesn't do this)
• AXTableSameLevelSearchKey (Chrome doesn't do this)
• AXUnderlineSearchKey

Comment 1

[Morgan Reschenberg [:morgan]]

Hey marco, can you rank these for me? I'd like to know which are more important to do!

Comment 2

[Marco Zehe (:MarcoZ)]

Here's my rank:

Priority 1

• AXBlockquoteSearchKey
• AXGraphicSearchKey
• AXHeadingLevelXSearchKey (1-6)

Priority 2

• AXBoldFontSearchKey
• AXItalicFontSearchKey
• AXUnderlineSearchKey
• AXDifferentTypeSearchKey (already done?)
• AXSameTypeSearchKey (already done?)
• AXOutlineSearchKey

Priority 3

• AXBlockquoteSameLevelSearchKey
• AXFontChangeSearchKey (Chrome doesn't do this)
• AXFontColorChangeSearchKey (Chrome doesn't do this)
• AXHighlightedSearchKey (Chrome doesn't do this)
• AXKeyboardFocusableSearchKey
• AXMisspelledWordSearchKey (Chrome doesn't do this)
• AXPlainTextSearchKey (Chrome doesn't do this)
• AXStyleChangeSearchKey (Chrome doesn't do this)
• AXTableSameLevelSearchKey (Chrome doesn't do this)

If some are already done, just push them in even if they're in the P2 section.

Comment 3

[Morgan Reschenberg [:morgan]]

oki eitan and I talked about this here's the problem:
To make stylized text search work, we have to be able to locate the text within its parent container using GetChildOffset. This is fine for the non-proxy case, but this method doesn't exist on proxy accessibles. Using StartOffset() instead doesn't work because stylized text is not embedded and so it fails the IsLink() assertion (or, the GetLinkAccessibleFromID in the RecvStartOffset() IPDL call).

there's a couple ways to solve this:

• we could implement a simple GetChildOffset sync IPC call to mirror the non-proxy version. this would be fine
• we could implement a more complex GetNextNodeWithTextAttribtue() function which would traverse the tree in search of a node or range that has the given style attribute. this could be useful in text marker land, though its not clear if it'd be the easiest or cleanest solution. we might get more bang for our buck though and avoid duplicating some code across the text/search predicate files.

ni'ing eeejay here to read this and add any context I missed 😀

Comment 4

[Eitan Isaacson [:eeejay]]

(In reply to Morgan Reschenberg [:morgan] from comment #3)

• we could implement a more complex GetNextNodeWithTextAttribtue() function which would traverse the tree in search of a node or range that has the given style attribute. this could be useful in text marker land, though its not clear if it'd be the easiest or cleanest solution. we might get more bang for our buck though and avoid duplicating some code across the text/search predicate files.

I think the exclusive consumer of this would be the search predicate API. I don't think it is needed in the text marker API. Some thought would need to be put in to the query language for the text attributes. Like "I want the next node that has an attribute equal to this", or "I want the next node with a different value for give attribute", or "I want the next node with a differing style than the current offset", lesser than font weight, greater than font weight, etc.

Comment 5

[Eitan Isaacson [:eeejay]]

The third option is to have specialized methods or a set enum of cases we need instead of a fancy query language so:

enum {
 eItalic,
 eUnderline,
 eFontChange,
 eFontColorChange,
 eMisspelled,
 eStyleChange,
 ...,
}