*** Bug 616886 has been marked as a duplicate of this bug. ***

[Resetting QA Contact to newly introduced "at-spi-maint@gnome.bugs". 
Reason: So far it was impossible to watch changes in at-spi bug reports without following all the specific persons (Li Yuan, Bill Haneman, Jeff Wai, ...) and also their activity outside of at-spi reports.

IMPORTANT: Anyone interested in following all bug activity (including all maintainers) must watch the "at-spi-maint@gnome.bugs" dummy user by adding it to the 'Users to watch' list under Preferences->Email preferences. This is also the default procedure nowadays in GNOME when setting up new products.]

[Mass-resetting default assignee, see bug 705890. Please reclaim this bug report by setting the assignee to yourself if you still plan to work on this. Thanks!]

Ok just to update. This has been partially fixed.

Insert seems to be working fine but delete is still problematic. The output as things are is:

object:text-changed:insert(0, 1, a)
	source: [text | ]
	application: [application | Java Application]
object:text-changed:insert(1, 1, b)
	source: [text | ]
	application: [application | Java Application]
object:text-changed:insert(2, 1, c)
	source: [text | ]
	application: [application | Java Application]
object:text-changed:delete(2, 1, )
	source: [text | ]
	application: [application | Java Application]
object:text-changed:delete(1, 1, )
	source: [text | ]
	application: [application | Java Application]
object:text-changed:delete(0, 1, )
	source: [text | ]
	application: [application | Java Application]

Yeah, essentially it's because the java AccessibleJTextComponent class method delete() doesn't directly translate to what's going on in ATK the way that insertTextAtIndex does[1,2]

So in java-atk-wrapper we have two methods which make use of the AccessibleJTextComponent methods :

	public void insert_text (String s, int position) {
		if (position < 0) {
			position = 0;
		}

		acc_edt_text.insertTextAtIndex(position, s);
	}

where the string s is the string being deleted and

	public void delete_text (int start, int end) {
		acc_edt_text.delete(start, end);
	}

Then in AtkWrapper.c these methods seem to be treated the same way so the problem is in figuring out how to get around the java API to get the information required and the question that follows is:

why is this data required for delete?

[1]https://docs.oracle.com/javase/8/docs/api/javax/swing/text/JTextComponent.AccessibleJTextComponent.html#delete
[2]https://docs.oracle.com/javase/8/docs/api/javax/swing/text/JTextComponent.AccessibleJTextComponent.html#insertTextAtIndex

(In reply to comment #5)
> why is this data required for delete?

As mentioned in the opening report:

   Impact:
   * Orca cannot indicate to the user which character was just deleted.

Which screen readers are expected to do when you use BackSpace or Ctrl+BackSpace to remove text as confirmation of what you just got rid of.

(In reply to comment #6)
> (In reply to comment #5)
> > why is this data required for delete?
> 
> As mentioned in the opening report:
> 
>    Impact:
>    * Orca cannot indicate to the user which character was just deleted.
> 
> Which screen readers are expected to do when you use BackSpace or
> Ctrl+BackSpace to remove text as confirmation of what you just got rid of.

That makes sense but on checking against gedit I'm not seeing the same results as are indicated in your initial report. Pehaps the API has changed since then?

It seems like the reason it is possible to obtain the string with insert is because the string to be inserted is in the argument.[1] This is not so on delete.[2] In other words, I think this might be an atk bug.

[1]https://developer.gnome.org/atk/unstable/AtkEditableText.html#atk-editable-text-insert-text
[2]https://developer.gnome.org/atk/unstable/AtkEditableText.html#atk-editable-text-delete-text

[Moving at-spi/java-atk-wrapper bugs to separate product. See bug 740075]

I can still reproduce this: the changed-delete event now contains text, but it's the text that remains, not the text being deleted.

It seems like it's the openjdk implementation which is not providing the correct information. 

https://docs.oracle.com/javase/7/docs/api/javax/accessibility/AccessibleContext.html#ACCESSIBLE_TEXT_PROPERTY says:

“
For text insertion, the oldValue is null and the newValue is an AccessibleTextSequence specifying the text that was inserted.
For text deletion, the oldValue is an AccessibleTextSequence specifying the text that was deleted and the newValue is null.
For text replacement, the oldValue is an AccessibleTextSequence specifying the old text and the newValue is an AccessibleTextSequence specifying the new text.
”

but in e.g. openjdk 11's ./src/java.desktop/share/classes/javax/swing/text/JTextComponent.java we can read:

public void insertUpdate(DocumentEvent e) {
...
firePropertyChange(ACCESSIBLE_TEXT_PROPERTY, null, pos);
...
}

public void removeUpdate(DocumentEvent e) {
...
firePropertyChange(ACCESSIBLE_TEXT_PROPERTY, null, pos);
...
}

public void changedUpdate(DocumentEvent e) {
...
firePropertyChange(ACCESSIBLE_TEXT_PROPERTY, null, pos);
...
}

So it's always only providing a new value, and it's just the position while it should be the text.

So we need to get that fixed in openjdk first.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/java-atk-wrapper/-/issues/8.