Bug Hunting Session
Bug 39694 - JAVA UNO API: XTextRange.getString returns correct String only after some delay
Summary: JAVA UNO API: XTextRange.getString returns correct String only after some delay
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.4.1 release
Hardware: x86 (IA32) Windows (All)
: high critical
Assignee: Michael Stahl (CIB)
URL:
Whiteboard: target:3.6.0 target:3.5.2 target:3.4.6
Keywords: regression
Depends on:
Blocks:
 
Reported: 2011-07-30 09:33 UTC by Bodo Meissner
Modified: 2012-03-07 03:36 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Program to reproduce text field placeholder problem (9.92 KB, text/x-java)
2011-07-30 09:33 UTC, Bodo Meissner
Details
sample document template to reproduce problem (40.33 KB, application/vnd.oasis.opendocument.text-template)
2011-07-30 09:33 UTC, Bodo Meissner
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bodo Meissner 2011-07-30 09:33:04 UTC
Created attachment 49745 [details]
Program to reproduce text field placeholder problem

When I load a document with text fields in a hidden window, then get the text fields from the enumeration XTextFieldsSupplier.getTextFields().createEnumeration() via UnoRuntime,
the method com.sun.star.text.XTextRange.getString() returns an empty string. Only after some delay this method returns the correct result.

The problem does not occur when the window is not hidden.
The problem does not occur with OpenOffice.org 3.3.0.

I tested this on Windows XP Professional SP3 German.

Attached is a sample program and a sample document. It needs ridl.jar, unoil.jar, juh.jar, unoloader.jar, jurt.jar.

The program contains hard coded references to LibreOffice or OpenOffice programs and to the document.
Comment 1 Bodo Meissner 2011-07-30 09:33:45 UTC
Created attachment 49746 [details]
sample document template to reproduce problem
Comment 2 Bodo Meissner 2011-07-30 09:53:25 UTC
Additional information regarding the program OO_LO_Placeholder_Test.java:

The main() function starts the LibreOffice or OpenOffice program using startOO_LO_Instance(), loads a document template using loadDocument() and gets all placeholder text fields as an ArrayList<XTextRange> using getPlaceholders().

Then it gets the first XTextRange element and calls getString() in a loop until the result's length is >0.
The loop counter shows how many calls were necessary to get the expected result.

Instead of the loop a delay of 1 sec somewhere between loading the document and calling XTextRange.getString() makes this method return the correct result.

After the loop the program does some sample replacement using replacePlaceholders().

With a visible window or with OpenOffice 3.3.0 the replacement can be done without any delay.
Comment 3 Oliver Brinzing 2011-07-31 07:50:23 UTC
confirming bug, lo3.4.2.rc3 and oo3.4beta1 are affected too.
oo 3.2/3,2.1 and oo 3.3 are ok.
Comment 4 Juergen Steinhilber 2011-08-01 08:50:53 UTC
Hi,
I'm convinced that the problem that LO.org >= 3.3 sometimes return an empty String, is simply one of the symptoms which are produced from a really great Bug.
The Bug solely occurs when a Document is opened in hidden state.
Funktions like printing or closing the "hidden" document are also affected from this Bug.

Jürgen Steinhilber
Comment 5 Oliver Brinzing 2011-08-03 05:31:56 UTC
adding a CallBack-Handler will not solve the problem - with attribute "hidden=true"  output is:

Document now available as XTextDocument
loop 100000 placeholder[0] = 
Replace placeholder[0] = empty placeholder name !!!!!! ...

"hidden=false" works fine ...
--

final XRequestCallback xAsyncCallback = AsyncCallback
		.create(xOfficeComponentContext);

xAsyncCallback.addCallback(new ExecuteAsyncron(), this.templateFile);

class ExecuteAsyncron implements XCallback {
	public void notify(final Object sUrl) {
		try {
			System.out.println("start Async Job exeute ...");
			executeJob((String) sUrl);
			System.out.println("finished Async Job exeute ...");
			try {
				ooloTests.release();
			} catch (Exception e) {
				e.printStackTrace();
			}
			System.exit(0);
		} catch (final com.sun.star.io.IOException e) {
			e.printStackTrace();
		}
	}
}

void executeJob(final String sUrl) throws com.sun.star.io.IOException {
	ooloTests.loadDocument();
         ...
}
Comment 6 Juergen Steinhilber 2011-08-04 02:23:51 UTC
if you do a refresh before enumerating the placeholdernames are all identified correctly, but it doesn't solve the real problem


        private ArrayList<XTextRange> testePlatzhalter(){
        	if(xTextDocument==null){return null;}

        	ArrayList<XTextRange> arrayList = new ArrayList<XTextRange>();
 		    try {
 	 		      XTextFieldsSupplier xTextFieldsSupplier = (XTextFieldsSupplier)UnoRuntime.queryInterface(XTextFieldsSupplier.class, xTextDocument);
 	 		      XEnumerationAccess xEnumerationAccess = xTextFieldsSupplier.getTextFields();
 	 		      //do a refresh() and all Placeholdernames can be found while hidden=true
 	 		      XRefreshable refresh = null;
 	 		      refresh = (XRefreshable)UnoRuntime.queryInterface(XRefreshable.class, xTextDocument);
 	 		      refresh.refresh();
 	 		      //but it doesn't solve the real problem which also occurs 
 	 		      //sporadically when printing or closing documents with hidden=true 
 	 		      XEnumeration xEnumeration = xEnumerationAccess.createEnumeration();
 	 		      while(xEnumeration.hasMoreElements()) {
 	 		        Object object = xEnumeration.nextElement();
 	 		        XTextField xTextField = (XTextField)UnoRuntime.queryInterface(XTextField.class, object);
 	 		        XServiceInfo xInfo = (XServiceInfo)UnoRuntime.queryInterface(XServiceInfo.class, xTextField);
 	 		        XTextRange range = xTextField.getAnchor();
 	 		        //Placehoders only
 	 		        if(xInfo.supportsService("com.sun.star.text.TextField.JumpEdit") /* || 
 	 		        		xInfo.supportsService("com.sun.star.text.TextField.User")*/){
 	 		          arrayList.add(range);
 	 		        }
 	 		      }
 		    }catch(Exception exception) {
 		    	exception.printStackTrace();
 		    }
 		    return arrayList;
	  }
Comment 7 Björn Michaelsen 2011-12-23 12:27:48 UTC
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Comment 8 Michael Stahl (CIB) 2012-03-02 09:59:11 UTC
this is a regression in OOo 3.4, from CWS sw34bf01 (8485708f3001fca132c3353c464fe7187ef62bed),
related to fix for issue 112425, issue 85766.

in that commit i had changed the expansion of Writer text fields
such that they are only actually expanded via the text formatting,
and all the other callers of SwField::ExpandField get a cached value,
because for many field types some setup is necessary to get a
correct value, which only the text formatting does properly.

this has introduced a race condition: if the field value is
requested before the layout of the document is complete,
an empty string may be returned.

@Bodo Meissner:
can you give a MPL/LGPLv3+ license for your attached template bug document?
i'd like to include a unit test for this, and just committing
that to our git repo would be easiest :)
Comment 9 Bodo Meissner 2012-03-02 11:38:48 UTC
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 02.03.2012 18:59, schrieb bugzilla-daemon@freedesktop.org:

> @Bodo Meissner:
> can you give a MPL/LGPLv3+ license for your attached template bug document?
> i'd like to include a unit test for this, and just committing
> that to our git repo would be easiest :)

@Michael Stahl:
The original document and test program were created by the main developer of the Thera-PI project (thera-pi.org), Jürgen Steinhilber, with an AGPL license. I modified both document and code to make them better suited for the bug report.
So for my changes I can agree to MPL/LGPLv3+ license. I think Jürgen Steinhilber will also agree if it helps fixing the problem in LibreOffice or OpenOffice.org. I added him as CC to get a confirmation.

> this has introduced a race condition: if the field value is
> requested before the layout of the document is complete,
> an empty string may be returned.

I think it would be OK if there was a way to check when the layout is complete. The application could wait for an event or poll for something before trying to access the fields.

Could a similar problem occur if the layout must be changed when the application has replaced some fields with text?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk9RGzAACgkQnMz9fgzDSqeybgCgjS/u4FxHPT5I67e8+qlzVEy5
cKoAmwfUCpUUx9iLOcy/FG5zFaOVBVZB
=h/sw
-----END PGP SIGNATURE-----
Comment 10 Not Assigned 2012-03-02 15:16:08 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9519deda120b73b72e75d89c3b2ae3d66220ec2d

fdo#39694: SwTxtFld: do expand the field in the ctor
Comment 11 Michael Stahl (CIB) 2012-03-02 15:16:38 UTC
fixed on master

bug 42073 is a different regression from the same change.

> I think it would be OK if there was a way to check when the layout is complete.

that is possible in principle by listening for the
"OnLayoutFinished" event at the global event broadcaster,
but unfortunately there is a bug (filed somewhere in issuezilla)
that this event is not sent for every document, just about 98% of them.
Comment 12 Juergen Steinhilber 2012-03-03 11:04:49 UTC
Hallo Herr Stahl, hallo Bodo,
natürlich(!) bin ich mit der jeweils erforderlichen Lizenz 
einverstanden, wobei es mir schleierhaft ist weshalb ein derart 
kümmerliches "Testprogrämmle" auch noch eine Lizenz braucht, aber ich 
muß ja auch nicht alles verstehen.
Schlußendlich ist es im ureigensten Interesse des Thera-Pi-Projektes, 
daß die Software auch mit LibreOffice betrieben werden kann.
Grüße
Jürgen Steinhilber

Reutlinger Therapie-&
Analysezentrum GmbH
Marie-Curie-Str.1
72760 Reutlingen
Tel. 07121 9617-20
Fax 07121 9617-22
Internet: http://www.rta.de


Am 02.03.2012 20:10, schrieb Bodo Meissner:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am 02.03.2012 18:59, schrieb bugzilla-daemon@freedesktop.org:
>
>> @Bodo Meissner:
>> can you give a MPL/LGPLv3+ license for your attached template bug document?
>> i'd like to include a unit test for this, and just committing
>> that to our git repo would be easiest :)
> @Michael Stahl:
> The original document and test program were created by the main developer of the Thera-PI project (thera-pi.org), Jürgen Steinhilber, with an AGPL license. I modified both document and code to make them better suited for the bug report.
> So for my changes I can agree to MPL/LGPLv3+ license. I think Jürgen Steinhilber will also agree if it helps fixing the problem in LibreOffice or OpenOffice.org. I added him as CC to get a confirmation.
>
>> this has introduced a race condition: if the field value is
>> requested before the layout of the document is complete,
>> an empty string may be returned.
> I think it would be OK if there was a way to check when the layout is complete. The application could wait for an event or poll for something before trying to access the fields.
>
> Could a similar problem occur if the layout must be changed when the application has replaced some fields with text?
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk9RGzAACgkQnMz9fgzDSqeybgCgjS/u4FxHPT5I67e8+qlzVEy5
> cKoAmwfUCpUUx9iLOcy/FG5zFaOVBVZB
> =h/sw
> -----END PGP SIGNATURE-----
>
Comment 13 Korrawit Pruegsanusak 2012-03-06 08:37:51 UTC
Now in -3-5 branch => will be available in 3.5.2 => set target accordingly.

http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=81828ab68a37715505b19988cdb4508ee0477c68
Comment 14 Michael Stahl (CIB) 2012-03-07 03:36:02 UTC
thanks Jürgen for the license, your test document (sans the images,
to save space) is now here:

cgit.freedesktop.org/libreoffice/core/commit/?id=0982257e5902a29c3faf90c0fa3dba809a2462e5

and the unit test:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=870e5a8e8251967b513b4255231ee9665b085431

because of the bugzilla outage it wasn't picked up automatically, so:

fixed in libreoffice-3-4 as well:

http://cgit.freedesktop.org/libreoffice/writer/commit/?h=libreoffice-3-4&id=bad17b39d1567c5f58c439093c8f8b692e106cdc