Bug 25669 - [GTK] Incorrect/missing caret-moved events when navigating across object boundaries
Summary: [GTK] Incorrect/missing caret-moved events when navigating across object boun...
Status: RESOLVED DUPLICATE of bug 30883
Alias: None
Product: WebKit
Classification: Unclassified
Component: Accessibility (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
Keywords: Gtk
Depends on:
Blocks: 25531
  Show dependency treegraph
Reported: 2009-05-10 11:14 PDT by Joanmarie Diggs (irc: joanie)
Modified: 2010-01-02 09:07 PST (History)
3 users (show)

See Also:

aforementioned test case (111 bytes, text/html)
2009-05-10 11:15 PDT, Joanmarie Diggs (irc: joanie)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joanmarie Diggs (irc: joanie) 2009-05-10 11:14:28 PDT
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.
Comment 1 Joanmarie Diggs (irc: joanie) 2009-05-10 11:15:31 PDT
Created attachment 30162 [details]
aforementioned test case
Comment 2 Joanmarie Diggs (irc: joanie) 2009-12-30 19:26:49 PST
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. :-)
Comment 3 Joanmarie Diggs (irc: joanie) 2010-01-02 09:07:21 PST
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 ***