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
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.
Summary: Screen readers incorrectly report line and column position → Screen readers incorrectly report line and char position
(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?
Go ahead if it's easy, but CSS columns are almost never used yet. So it's just not critical for Firefox 3.
Surkov, just do line-number only.
Summary: Screen readers incorrectly report line and char position → Screen readers incorrectly report line position
Created attachment 291768 [details] [diff] [review] WIP
Assignee: surkov.alexander → aaronleventhal
Status: NEW → ASSIGNED
Created attachment 291770 [details] [diff] [review] 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.
Attachment #291768 - Attachment is obsolete: true
Created attachment 291771 [details] [diff] [review] 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
Attachment #291770 - Attachment is obsolete: true
Created attachment 291813 [details] [diff] [review] 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
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?
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.
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.
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.
Created attachment 292049 [details] [diff] [review] 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).
Attachment #292049 - Flags: review?(ginn.chen)
Attachment #292049 - Flags: superreview?(roc) → superreview+
Does making GetFrameForNodeOffset virtual have any performance impact?
Robert, can you answer Mike's question in comment 14? I'm not sure.
No significant impact.
Checked in line-number object attribute support. Will be in 12/12 builds.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.