353293 - getCharacterExtentsCB is not called when caret browsing with magnifier open

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect)

Description

[Evan Yan]

this bug is seperated from bug 349860.

set breakpoint in gdb for the function, it is never hit when inputting or caret browsing with magnifier open.

I'm using gnopernicus 1.1.2.
It works on branch 1.8 with the same magnifier.

Comment 1

[Aaron Leventhal]

Are we firing caret move events?

Comment 2

[Evan Yan]

(In reply to comment #1)
> Are we firing caret move events?
> 
yes, after bug 349860 fixed, caret-move and text-change events are fired now.

Comment 3

[Aaron Leventhal]

Why is this a build config bug?

Comment 4

[Evan Yan]

sorry, I didn't mean it. it was changed by accident.

Comment 5

[Evan Yan]

tested with orca, when inputting, getCharacterExtentsCB is called and magnifier works well; but when caret browsing, the function is never called, which makes magnifier not work.

Comment 6

[Aaron Leventhal]

It may be an issue of rich content vs. plain text.

For example, this is editing, but in rich text:
http://www.mozilla.org/editor/midasdemo/

Does getCharacterExtentsCB get called then?

Comment 7

[Evan Yan]

(In reply to comment #6)
> http://www.mozilla.org/editor/midasdemo/
> 
> Does getCharacterExtentsCB get called then?
> 
yes, it's called. rich content seems not the point.

Comment 8

[Evan Yan]

Attachment: testcase

here is a python script, to call getCharacterExtentsCB when received a caret_moved event.

just run the testcase, then inputting or caret browsing in firefox. we can get the extent correctly.

Will, could you help to investigate this bug from Orca's side? to figure out what makes firefox not work with magnifier. 
Thanks a lot!

Comment 9

[Willie Walker]

I just enabled caret browsing in a 25-Oct nightly of FF3.  With caret navigation enabled in FF3 and magnification on in Orca from GNOME CVS HEAD, Orca seems to track the caret just fine.  The only problems I see are:

1) If the caret is at the end of a line, text.getCharacterExtents for the caret returns (x=0, y=0, width=0, height=0).  I've not run across this in GTK+ apps (they return the area at the end of the line, I believe), so I'm not sure if this is a bug in Orca or Gecko.  I'll probably need add some more defensive code to Orca, though, to cover this situation -- right now, what ends up happening is that the region of interest jumps to (0, 0, 0, 0) when the user moves the caret to the end of a line.

2) It's my understanding that getting reliable caret navigation from Gecko is a lost cause.  As such, we are forced to write our own support in Orca to do caret navigation for Gecko and we will be updating the magnification region of interest via additional means.  Since the FF team seems rather keen on fixing this particular problem, though, maybe there is hope that someone will want to fix caret navigation in general?  It certainly would help eliminate the need to have every assistive technology write its own navigation code.

If you're interested, please look at the mag.py:magnifyAccessible method in orca/src/orca/mag.py for what we're doing to update the region of interest.  This will, of course, need to get a little more complex since we'll be doing our own caret navigation mechanism and cannot rely upon obj.text.caretOffset to be of any use.

Comment 10

[Willie Walker]

Attachment: Sample app to watch caret motion

Here's a sample test app for you. Hope it helps.

Comment 11

[Evan Yan]

Thank you, Will!

I tried the latest version of orca and firefox, and it's OK. It must be the problem of that snapshot which I was testing.
Close as WORKSFORME.

About the problem of return (0, 0, 0, 0) at the end of a line, it's because getCharacterExtents returns the extent of the character AFTER the caret offset. When the caret is at the end of a line, there is no character after the caret, so (0, 0, 0, 0) will get returned.

Comment 12

[Firefox Bug Husbandry Bot]

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