1016574 - Provide APIs for word/line/character bounds and navigation, also for generated content and bullets (primarily for a11y needs)

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect, P5)

Description

[Mats Palmgren (inactive)]

Spawned off from bug 987023.

There are +1000 lines of code in a11y that pokes about in low-level
nsIFrame implementation details to get the information it needs,
such as gfxSkipChars:
http://mxr.mozilla.org/mozilla-central/source/accessible/src/generic/HyperTextAccessible.cpp#1721

This is very unfortunate and I'd like to replace it with code that
uses higher level content/range/selection APIs.  Here's a brief
description of what is needed:

(Trevor Saunders (:tbsaunde) from bug 987023 comment #29)
> The issues with using just content stuff that I can think of are
> - text from css generated content and list bullets
> - line / word / navigation is tied in with nsSelection and that's sort of
> tied into frames.
> 
> The basic stuff is grab all the text under a DOM node, break it up by words
> / lines / characters, then you need to be able to provide bounds for each of
> those objects.  You also need to be able to select / unselect chunks of
> text, but that's mostly deligated to selection code.  basically you need to
> implement accessible/public/nsIAccessible{Hyper,Editable,}text.idl for every
> DOM node.

Comment 1

[Trevor Saunders (:tbsaunde)]

> There are +1000 lines of code in a11y that pokes about in low-level
> nsIFrame implementation details to get the information it needs,
> such as gfxSkipChars:
> http://mxr.mozilla.org/mozilla-central/source/accessible/src/generic/
> HyperTextAccessible.cpp#1721
> 
> This is very unfortunate and I'd like to replace it with code that
> uses higher level content/range/selection APIs.  Here's a brief

yeah, I'd definitely like to see something better if you want to make it better, but it seems rather nontrivial, and I'm not sure how much sense there is in having an API with one consumer, though maybe it would be useful to editor and selection stuff too.

Comment 2

[(no longer active)]

Having this kind of API will also help the spellchecker code, which currently has to do nasty things to implement this.

Comment 3

[alexander :surkov (:asurkov)]

I agree that moving out gfxSkipChars stuff from a11y code is nice thing but I don't have a good idea about proposed API requirements. So it'd be good to outline requirements of other potential consumers like spellchecker. Concerning to a11y requirements the API designer need to keep in mind that 1) a11y works with rendered offsets while spellchecker/editor presumably works with content offsets 2) a11y requirements might be over the needs of spellchecker etc (for example a11y needs to navigate both from word start to word start or from word end to word end).

Further, we have bug 634202 which is supposed to switch from PeekOffset API to some API that allows to navigate arbitrary string (source (like frame tree?)) by lexems (words, lines, paragraphs).

Comment 4

[Mats Palmgren (inactive)]

IIUC, the detailed layout info needed here will be provided by the Houdini APIs.

roc, please make it so :-)

Comment 5

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.

Comment 6

[James Teh [:Jamie]]

a11y::TextLeafRange removed quite a lot of this stuff. In particular, we no longer use gfxSkipChars or PeekOffset. However, we do still use layout for lines, character rects, etc. The requirements have changed quite a bit, though. In particular, we need to be able to iterate lines all at once or on demand, rather than only on demand.

No one in a11y sees benefit in creating a specific DOM API and I don't think anyone in DOM is interested in working on this either. Closing, but please reopen if I'm incorrect.