Bug 82950 - XTextFieldsSupplier delivers wrong Field type
Summary: XTextFieldsSupplier delivers wrong Field type
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.2.4.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-22 14:20 UTC by Stefan Ziel
Modified: 2017-09-20 14:04 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
One of the affected documents (63.70 KB, application/vnd.oasis.opendocument.text)
2014-08-22 14:20 UTC, Stefan Ziel
Details
An affected document with a macro to show the error (65.17 KB, application/vnd.oasis.opendocument.text)
2014-11-13 14:05 UTC, Stefan Ziel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Ziel 2014-08-22 14:20:15 UTC
Created attachment 105104 [details]
One of the affected documents

Enumerating all text fields of some writer documents using 

XTextFieldsSupplier.getTextFields().createEnumeration();

the first n fields are reported as com.sun.star.text.textfield.PageNumber but they actually are com.sun.star.text.textfield.User

Iterating the document paragraph by paragraph this does not happen

The behavior can be reproduced under Linux and Windows using Open JDK 1.7 and Oracle Java 1.7, Writer 4.2.4.2 and 4.1.5.3
Comment 1 Stefan Ziel 2014-08-22 16:12:10 UTC
Inverting the access using getTextFieldMasters() the field master exists but the DependentTextFields property has less entries than expected.
Comment 2 Stefan Ziel 2014-08-25 20:16:55 UTC
Te fact is related with tables - removing the tables everything is alright.
Comment 3 Buovjaga 2014-11-13 10:17:31 UTC
Can you give more detailed steps for reproduction, so any random QA team member without prior experience with scripting can test this? Change back to UNCONFIRMED after supplying the information.
Comment 4 Stefan Ziel 2014-11-13 14:05:41 UTC
Created attachment 109406 [details]
An affected document with a macro to show the error

Added a macro called "TestCase" that lists the ServiceNames of all userfields in the document. just call the macro. After a wile a message box shows up and the first twenty lines will show "PageNumber"
Comment 5 Buovjaga 2014-11-14 06:24:45 UTC
(In reply to Stefan Ziel from comment #4)
> Created attachment 109406 [details]
> An affected document with a macro to show the error
> 
> Added a macro called "TestCase" that lists the ServiceNames of all
> userfields in the document. just call the macro. After a wile a message box
> shows up and the first twenty lines will show "PageNumber"

Reproduced.

Win 7 64-bit Version: 4.4.0.0.alpha2+
Build ID: b021b5983c62e266b82d9f0c5c6d8d8900553827
TinderBox: Win-x86@39, Branch:master, Time: 2014-11-12_01:10:08
Comment 6 Björn Michaelsen 2015-11-21 11:12:06 UTC
Adjusting importance as per https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Severity. No "crashes, loss of data, severe memory leak, major loss of function", but "regular issue, some loss of functionality under specific circumstances".
Comment 7 Björn Michaelsen 2015-11-21 11:13:08 UTC
(also component: writer as that is where it needs to be fixed)
Comment 8 QA Administrators 2017-01-03 19:35:26 UTC Comment hidden (obsolete)
Comment 9 Oliver Specht (CIB) 2017-09-20 12:53:21 UTC
This is not a bug. 
The order of the fields returned from getTextFields enumeration is not related to the order of the paragraphs. It returns the fields in an implementation dependent order.
Comment 10 Buovjaga 2017-09-20 14:04:32 UTC
(In reply to Oliver Specht (CIB) from comment #9)
> This is not a bug. 
> The order of the fields returned from getTextFields enumeration is not
> related to the order of the paragraphs. It returns the fields in an
> implementation dependent order.

Ok, closing.