405810 - Screen readers incorrectly report line position

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Aaron Leventhal]

We need to support the following text attributes on any root accessible editable text object that has focus.

These attributes report the current position of the caret in user-centric terms. Like groupPosition() the screen reader can use these more efficiently than calculating the info itself.

Most important:
line-number:[unsigned int]
column-number:[unsigned int]

Would be useful:
total-columns:[unsigned int] -- only expose for plain text editors, because it does not make sense for a proportional font.
total-lines:[unsigned int]

Future:
In the future if we ever get any kind of page breaks in our editor we would also want to expose:
page-name
page-number
total-pages

Comment 1

[Aaron Leventhal]

It turns out the column stuff is for newspaper columns. We don't need to support that yet.

So, let's just focus on line-number. They'll fix their code to compute the char position.

Comment 2

[alexander :surkov (:asurkov)]

(In reply to comment #1)
> It turns out the column stuff is for newspaper columns. We don't need to
> support that yet.

Why not?

Comment 3

[Aaron Leventhal]

Go ahead if it's easy, but CSS columns are almost never used yet. So it's just not critical for Firefox 3.

Comment 4

[Aaron Leventhal]

Surkov, just do line-number only.

Comment 5

[Aaron Leventhal]

Attachment: WIP

Comment 6

[Aaron Leventhal]

Attachment: WIP #2 (alert events are for debugging, temporary)

For heading following by regular text, the regular text line #s don't work. Vice versa it does work.

Comment 7

[Aaron Leventhal]

Attachment: Closer, but it still seems to count the previous blocks' lines slightly erratically. It may be counting blank lines between blocks but it doesn't quite seem that way

Comment 8

[Aaron Leventhal]

Attachment: 1) Allow object attributes on doc accessible, 2) For a focused hypertext, expose line number for focused node/offset of selection

This is correctly reporting line-number for input, textarea, designMode and contentEditable

Comment 9

[alexander :surkov (:asurkov)]

I thought it should be text attribute.

Isn't the simple version of line-number from patch of bug 345759 suitable for us? Do we need to accumulate line numbers in accessible?

Comment 10

[Aaron Leventhal]

Surkov, no it shouldn't be a text attribute:
1) We need to mimic what Lotus Notes ODF support has, which is already supported in some screen readers
2) Doing it as a text attribute would inconveniently break up other text attribute runs.

Comment 11

[Aaron Leventhal]

Surkov, I'm sorry, when I wrote up the bug I said text-attributes. My fault.

I just verified with Pete Brunet that it needs to be an object attribute.

So, the current patch would appear to be correct.

Comment 12

[Ginn Chen]

I think "line number" is not a good word to describe the attribute.
maybe we should use "caret in line" or something else.

And, frameSelection->GetFrameForNodeOffset can't be called from libaccessibility.so.
So we have a problem if not enable-static.

Comment 13

[Aaron Leventhal]

Attachment: Forgot nsFrameSelection.h

Ginn, I forgot to include nsFrameSelection.h in patch for review-- this should remove concerns about building successfully

We can't change the name line-number. It's already used in shipping products (Lotus Symphony and some Windows screen readers).

Comment 14

[Mike Schroepfer]

Does making GetFrameForNodeOffset virtual have any performance impact?

Comment 15

[Aaron Leventhal]

Robert, can you answer Mike's question in comment 14? I'm not sure.

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

No significant impact.

Comment 17

[Aaron Leventhal]

Checked in line-number object attribute support. Will be in 12/12 builds.