This is not a gail 'bug', since we don't guarantee the state of the text when
the delete event is fired.  However the patch in bug 161271 is probably useful.

Created attachment 38785 [details] [review]
proposed patch

The attached patch is from bug #161271.

Comment on attachment 38785 [details] [review]
proposed patch

thanks Oana, please commit!

Comment on attachment 38785 [details] [review]
proposed patch


Patch committed on cvs head.

Patch containes line:

+      gail_entry->length_delete = arg2 - arg2;

This should be:

+      gail_entry->length_delete = arg2 - arg1;

please fix and commit. thanks!

Fixies applied to cvs.

THanks Remus.

It seems this patch was a mistake, since it makes it impossible to fulfill the at-spi contract calling for the TextChangeEvent to return the change string.

While firing the event after the change has been made means that clients can re-read the entire text contents on notification, and get something that's probably reasonably current (unless new changes are being made during the query), the "fire on idle" solution has made it impossible to provide the proper change string to at-spi.  Ideally the notification would be fired synchronously _just before_ gtk+ modifies the text buffer, so that atk-bridge would be able to extract the change string in the expected manner, but subsequent queries would see the updated data instead.  (Firing the notification at that time may not be feasible, depending on what gtk+ signals are available).

While gail can of course obtain and cache the change string, it's unclear how it could be communicated to atk-bridge via the existing ATK API.

Looks like this was commited and never reverted. Marking the patch as commited.

I think it should be OK to revert the patch. The text_changed::delete signal tells the callback which charcaters are removed. If ATs wants, they can compute what current text like. Plus, Orca doesn't read the hole text when user press delete. It just read the deleted text.

The problem has been fixed.