Bug 25669 – [GTK] Incorrect/missing caret-moved events when navigating across object boundaries

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Accessibility

[Joanmarie Diggs]

Steps to reproduce:

1. Open the (to be) attached test case.

2. Enable monitoring of object:text-caret-moved events in Accerciser.

3. Position the caret to the left of the link in the test case and move forward character by character using Right Arrow.

Expected results: When the caret is at the 'i' of the link 'is', a caret-moved event would be emitted for the link with an offset of 0. Similarly, when the caret is just past the 's' of the link 'is' (and is thus at the space of ' a test'), a caret-moved event would be emitted for the text object ' a test' with an offset of 0.

Actual results: When the caret is at the aforementioned positions, a caret-moved event is issued for the object that had the caret, with an offset of 1 + the previous offset. From Accerciser:

  object:text-caret-moved(4, 0, None)
	source: [text | This ]
  object:text-caret-moved(5, 0, None)
	source: [text | This ]     <-- caret at offset 0 of 'is'
  object:text-caret-moved(1, 0, None)
	source: [text | is]
  object:text-caret-moved(2, 0, None)
	source: [text | is]        <-- caret at offset 0 of ' a test'
  object:text-caret-moved(1, 0, None)
	source: [text |  a test.]

Note: It's not so much that the above events are incorrect as it is the events for the new objects and offsets are missing. In other words, if it's easier to continue to emit the events currently being emitted as a way to say "The caret has left this object" but then follow those events with the requested events, that's fine. If you want to replace the above events with the requested events, that's fine too. :-) What's important is that:

1. We get the event for the new object and offset (because that lets ATs such as Orca know what character needs to be spoken as well as presented as the current character on the braille display).

2. If an AT asks for the caretOffset for an object which does not have the caret, an offset that suggests this fact (e.g. -1 or the character count of that object) is returned.

[Joanmarie Diggs]

Created attachment 30162 [details]
aforementioned test case

[Joanmarie Diggs]

Making a depends on 30883 because in that bug I'm flattening the hierarchy w.r.t. text objects. Those changes may just fix this bug completely, but if they do not, they will still most certainly impact this bug as the offending text objects in this bug will no longer exist. :-)

[Joanmarie Diggs]

This bug is indeed fixed by my second proposed patch to bug 30883. While technically not a dup, this instance of Bugzilla seems to lack a resolution of OBSOLETE. So I'm dup'ing it to get it off our to-do list.

*** This bug has been marked as a duplicate of bug 30883 ***