GNOME Bugzilla – Bug 151579
Gnopernicus looses line's content in OpenOffice reading by character.
Last modified: 2004-12-22 21:47:04 UTC
Please describe the problem: When you are reading a line character by character in OpenOffice, if you delete a character and go on forward and backward reading with the left and right arrow, Gnopernicus stop reading until you down or up arrow and give focus again to the text line or paragraph. Steps to reproduce: Start up OpenOffice and write a couple of text's line in a new document.1. 2. Go to the home of the line. And right arrow, You'll be able hearing the line content character by character. 3. Until reach to the end of the line, delete a character pressing delete key or backspace. And try reading with the left or right arrow. Actual results: Gnopernicus stop reading the text, Seems loosing the focus. Expected results: It should read the other characters in the text line. Does this happen every time? Start up OpenOffice and write a couple of text's line in a new document.1. 2. Go to the home of the line. And right arrow, You'll be able hearing the line content character by character. 3. Until reach to the end of the line, delete a character pressing delete key or backspace. And try reading with the left or right arrow. Other information: If you up or down arrow and come back to the line Gnopernicus reads the text without any problem. I am running Gnopernicus 0.9.10, at-spi 1.53, gnome java bridge 1.4.2 j2sdk 1.4.2-04 and GNOME 2.7.4
Same behavior hapends in Sun Mozilla 1.7 built in edit fields, example in www.google.com in the search for text field.
This problem are present because of differences between GTK apps, SO and Mozilla. In order to actualise the current number of characters (after deleting one/some char/s), we use the details (detail1 and detail2) from the at-spi 'object:taxt-changed:delete' event. 1)GTK apps: detail1=offset after the char was deleted, detail2=no of deleted characters (this is what gnopernicus expects to receive! No of current characters will be decreased with detail2) 2)SO: detail1=offset after the char was deleted, detail2=offset before delete the char (No of current characters should be decreased in this case with detail2-detail1...) 3)Mozilla: detail1=offset before delete the char, detail2=0 (I believe this is a bug, we can not find the number of deleted characters. In case of inserting a char, detail2=1. Why if we delete a char it is 0?) For example, if the current offset is 5 and we delete 1 char (by pressing backspaces) the results are: 1)GTK apps: detail1=4, detail2=1 2)SO: detail1=4, detail2=5 3)Mozilla: detail1=5, detail2=0
Anny suggestions about how to deal with first two situations?
There are clearly two bugs here. The bug in Mozilla is very clear. The issue of SO vs. GTK is another question. Dana - what happens with Swing JTextComponent text (e.g. Stylepad)? Whether GTK is "correct" or not, both GTK and SO contain the same information content exposed in different ways. I think the decision will come down to which is easier to fix... (fixing SO/Java in the bridge may be the easiest...). Bill?
I checked with Stylepad and there is the same situation like for GTK apps: detail1=offset after the char was deleted, detail2=no of deleted characters. So I believe the fix should be done in SO.
Bug https://bugzilla.mozilla.org/show_bug.cgi?id=260921 was filed against mozilla to describe issue 3), comment #2
Dana - given your observation (Stylepad same as GTK) then I agree SO should change. Would you also please file a bug in OO.o's issue tracker?
Bug http://www.openoffice.org/issues/show_bug.cgi?id=34527 was filed against SO.
Since the two issues was reported in the right places (Mozilla and SO), I will close this bug as NOTGNOME.
Peter & Dana - I disagree with your conclusion regarding SO/OOo: currently SO/OOo and the JABG use a private protocol for text change notifications because Java 1.4 does not have an appropriate structure/object to pass. However the notion of startIndex / endIndex corresponds exactly to the new interfaces introduced in Java 1.5 (see http://java.sun.com/j2se/1.5.0/docs/api/index.html), so I believe this should be fixed in the JABG.
Created attachment 31985 [details] [review] simple patch for JavaBridge.java Calculating the number of deleted chars in the gnome-java-bridge.
Dana, could you please test if the attached patch fixes your problem ? Thanks.
I verified the patch, it seems to solve the problem, so it should be applied.
Transferring to at-spi.
Patch committed to CVS HEAD.