Open Bug 613857 (getText*a11y) Opened 11 years ago Updated 8 years ago

fix getText* behaviour

Categories

(Core :: Disability Access APIs, defect)

x86
Linux
defect
Not set
normal

Tracking

()

People

(Reporter: fherrera, Unassigned)

References

(Depends on 6 open bugs, Blocks 1 open bug)

Details

(Keywords: meta)

Attachments

(1 file)

Currently getText functions are returning very different results from expected.

This issue here is that nsHyperTextAccessible::GetRelativeOffset uses nsIFrame::PeekOffset to calculate those offsets, and that implementation doesn't take into account stuff needed fot getText (mostly if current offset is ok for start or we should take previous or next).

So there are 3 options:
1) Still use PeekOffset but woraround/wrap at GetRelativeOffset to match getText expected interpretation
2) Modify PeekOffset to take into account getText needs
3) Use a completely new code to calculate offsets

Option 1) should not be that hard for the WORD and CHAR case, but LINE could be more ugly because PeekOffset considers "\n" as a word
Option 2) scares me, because there is a lot of rendering code depending on that behaviour
for Option 3) we may use nsILineBreaker and nsIWordBreaker so we don't have to rewrite the whole logic

What do you think?

As an example I'm attaching a patch exploring Option 1), that get proper results for CHAR and WORD cases (1008 ok vs 152 Fails for the singleline test case, 1277 vs. 51) but haven't yet tried to fix LINE (527 ok vs. 538 fails). The remaining fails for CHAR and WORD are mostly textarea adding an extra \n and out of boundary test.
Blocks: 433667
Can you make your patch to contain function names, i.e. please use standard options to create a patch.

existing code makes me scary since it's not very well readable, so I'm not fan for option 1.

if we need to change layout for option 2 then it should be very careful considered, like does it come with PeekOffset propose and etc.

I'm for option 3 since it can reuse existing code, we should look if it's optimal and works as we expect for rich text.

Perhaps I would go to make new algorithm trying to keep it plain as possible.

But we need to finish all tests before taking this patch and (would be nice) before reviewing.
Depends on: 853340
Depends on: 493354
No longer blocks: 433667
Depends on: 433667
Depends on: 631009
Alias: getText*a11y
Keywords: meta
Depends on: 853361
Depends on: 855184
Depends on: 857476
Depends on: 860013
Depends on: 861062
Depends on: 872397
Depends on: 873322
Depends on: 873354
Depends on: 873358
Depends on: 875280
Depends on: 876540
Depends on: 875794
Depends on: 877974
Depends on: 877976
Depends on: 877977
Depends on: 878515
Depends on: 878757
Depends on: 879130
Depends on: 880159
Depends on: 882281
No longer depends on: 875794
No longer depends on: 877974
No longer depends on: 877976
No longer depends on: 878515
No longer depends on: 877977
No longer depends on: 878757
No longer depends on: 879130
Depends on: 882647
Depends on: 893166
Depends on: 896326
Depends on: 899433
Blocks: 2013q4a11y
No longer depends on: 2013q4a11y
Depends on: 935254
Depends on: 935375
Depends on: 943603
Depends on: 947170
Depends on: 957306
Depends on: 967631
You need to log in before you can comment on or make changes to this bug.