Bug Hunting Session
Bug 67109 - REPORTBUILDER - The labels displayed in some options lists do not match the functionality
Summary: REPORTBUILDER - The labels displayed in some options lists do not match the f...
Status: CLOSED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
4.1.0.0.beta2
Hardware: Other All
: medium major
Assignee: Stephan Bergmann
URL:
Whiteboard: target:4.2.0 target:4.1.1
Keywords: regression
: 68188 68190 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-07-20 07:54 UTC by pierre-yves samyn
Modified: 2013-09-09 07:33 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Database with a report (10.37 KB, application/vnd.oasis.opendocument.base)
2013-07-20 07:54 UTC, pierre-yves samyn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description pierre-yves samyn 2013-07-20 07:54:06 UTC
Created attachment 82718 [details]
Database with a report

Hello

Platform: windows 7 64bits & Version: 4.1.0.3
Build ID: 719826cd009b9a1fa43e253db0616288c682826

The labels displayed in some options lists do not match the functionality.

It seems that several options are concerned. For example, the "page break" property of a section.

Steps to reproduce

1. edit the report of the attached database. This database was created with an earlier version with the "Force New Page" setting ("Nom header" section) set to "none".
2.Select the "Nom header" section to display its properties.

Expected Result: "Force new page" = none
Actual result: "Force new page" = Before & After Section

Below Parameter => Effect

None => After section
Before => Before & After
After => Before
Before & After => None

This normally worked in 4.0.4

Same disorder for properties "Page header", "Page footer" of a report. May be other options...

Severity set to major because the user is leaded to modify the database by specifying parameters to be wrong with another version.

Regards
Pierre-Yves
Comment 1 marc.romano 2013-07-20 08:14:59 UTC
I confirm with :

- Windows 8 pro 64 bits
- LibO 4.1.0.1 build 1b3956717a60d6ac35b133d7b0a0f5eb55e9155

Best regards
Marc
Comment 2 royerjy 2013-07-20 10:10:13 UTC
I confirm with 4.1.0 rc3 with Windows XP et Ubuntu 12.04.
Comment 3 Robert Großkopf 2013-08-07 07:42:54 UTC
Have tested it a little bit. With LO 4.1.0.0 beta1 I couldn't start any report - LO crashes immediately. Also couldn't edit. In LO 4.1.0.0 beta2 the reported behavior appears the first time.
Have only tested it for the menu "Force new Page" - shows "Before and after Section", where the other versions of LO show "None". Executes "None".

All test were made with OpenSUSE 12.3 64bit rpm.
Comment 4 Robert Großkopf 2013-08-16 15:35:48 UTC
*** Bug 68190 has been marked as a duplicate of this bug. ***
Comment 5 Robert Großkopf 2013-08-16 15:36:21 UTC
*** Bug 68188 has been marked as a duplicate of this bug. ***
Comment 6 Robert Großkopf 2013-08-16 15:41:11 UTC
Hi Lionel,

could you please have a look. Or Do you know somebody who had changed something there?
Isn't only the sorting of functionality and menue-entry, but also the translation, which had been gone ...
(https://bugs.freedesktop.org/show_bug.cgi?id=67112)
Comment 7 Lionel Elie Mamane 2013-08-17 09:12:53 UTC
Stephan? Could you please take a look at this? It looks related to the new unoidl module, which git log tells me is basically your code.

So, what happens is that
 cppuhelper::TypeManager::getByHierarchicalName (this=0x18b6d80, aName="com.sun.star.report.ForceNewPage")
returns a descriptor where the constants are not anymore in a strictly increasing order, but offset by two (value 2, 3, 0, 1 instead of value 0, 1, 2, 3) 

Here is how it gets to unoidl:

#0  unoidl::UnoidlProvider::find (this=0x18ad260, name="com.sun.star.report.ForceNewPage", constant=0x7f0e0e6b2b1b)
    at /home/master/src/libreoffice/workdirs/master/unoidl/source/unoidlprovider.cxx:1239
#1  0x00007f0e37800699 in unoidl::UnoidlProvider::findEntity (this=0x18ad260, name="com.sun.star.report.ForceNewPage")
    at /home/master/src/libreoffice/workdirs/master/unoidl/source/unoidlprovider.cxx:1209
#2  0x00007f0e377f2fd6 in unoidl::Manager::findEntity (this=0x18b69b0, name="com.sun.star.report.ForceNewPage")
    at /home/master/src/libreoffice/workdirs/master/unoidl/source/unoidl.cxx:131
#3  0x00007f0e3c13eed6 in cppuhelper::TypeManager::findEntity (this=0x18b6d80, name="com.sun.star.report.ForceNewPage")
    at /home/master/src/libreoffice/workdirs/master/cppuhelper/source/typemanager.cxx:2376
#4  0x00007f0e3c13b7c8 in cppuhelper::TypeManager::find (this=0x18b6d80, name="com.sun.star.report.ForceNewPage")
    at /home/master/src/libreoffice/workdirs/master/cppuhelper/source/typemanager.cxx:1919
#5  0x00007f0e3c13bf54 in cppuhelper::TypeManager::getByHierarchicalName (this=0x18b6d80, aName="com.sun.star.report.ForceNewPage")
    at /home/master/src/libreoffice/workdirs/master/cppuhelper/source/typemanager.cxx:1989
#6  0x00007f0e0e834f88 in pcr::StringRepresentation::initialize (this=0x304d5e0, aArguments=uno::Sequence of length 3 = {...})
    at /home/master/src/libreoffice/workdirs/master/extensions/source/propctrlr/stringrepresentation.cxx:246
#7  0x00007f0e3c0ac275 in cppu::OSingleFactoryHelper::createInstanceWithArgumentsAndContext (this=0x377ae68, 
    rArguments=uno::Sequence of length 3 = {...}, xContext=uno::Reference to (cppu::ComponentContext *) 0x3675ce0)
    at /home/master/src/libreoffice/workdirs/master/cppuhelper/source/factory.cxx:218


*but* pcr::StringRepresentation::convertSimpleToString
very much assumes that its m_aConstants and m_aValues are in the same order. m_aValues is in "strictly increasing" order, but m_aConstants comes from  cppuhelper::TypeManager::getByHierarchicalName("com.sun.star.report.ForceNewPage")->getConstants()
while m_aValues comes from the initialiser of pcr::StringRepresentation (and is in strictly increasing value order).

The same holds for pcr::StringRepresentation::convertStringToSimple

Here's how the last one is invoked:

#0  pcr::StringRepresentation::convertStringToSimple (this=0x3484c10, _rValue="Before & After Section", 
    _ePropertyType=@0x7f0e0e6b31bc: com::sun::star::uno::TypeClass_SHORT)
    at /home/master/src/libreoffice/workdirs/master/extensions/source/propctrlr/stringrepresentation.cxx:457
#1  0x00007f0e0e834b6f in pcr::StringRepresentation::convertToPropertyValue (this=0x3484c10, ControlValue="Before & After Section", 
    ControlValueType=invalid uno::Type)
    at /home/master/src/libreoffice/workdirs/master/extensions/source/propctrlr/stringrepresentation.cxx:199
#2  0x00007f0e0f10aa48 in rptui::GeometryHandler::getConstantValue (this=0x2d8a9e0, _bToControlValue=0 '\000', _nResId=30769, 
    _aValue=uno::Any "Before & After Section", _sConstantName="com.sun.star.report.ForceNewPage", PropertyName="ForceNewPage")
    at /home/master/src/libreoffice/workdirs/master/reportdesign/source/ui/inspection/GeometryHandler.cxx:955
#3  0x00007f0e0f10acd9 in rptui::GeometryHandler::convertToPropertyValue (this=0x2d8a9e0, PropertyName="ForceNewPage", 
    _rControlValue=uno::Any "Before & After Section")
    at /home/master/src/libreoffice/workdirs/master/reportdesign/source/ui/inspection/GeometryHandler.cxx:968
#4  0x00007f0e0e72230d in pcr::OBrowserListBox::impl_getControlAsPropertyValue (this=0x3849490, _rLine=...)
    at /home/master/src/libreoffice/workdirs/master/extensions/source/propctrlr/browserlistbox.cxx:955
#5  0x00007f0e0e72287c in pcr::OBrowserListBox::valueChanged (this=0x3849490, _rxControl=
    uno::Reference to (pcr::OListboxControl *) 0x37b5280)
    at /home/master/src/libreoffice/workdirs/master/extensions/source/propctrlr/browserlistbox.cxx:1011
#6  0x00007f0e0e71eed8 in pcr::PropertyControlContext_Impl::impl_processEvent_throw (this=0x391f3c0, _rEvent=...)
    at /home/master/src/libreoffice/workdirs/master/extensions/source/propctrlr/browserlistbox.cxx:337
#7  0x00007f0e0e71ed4b in pcr::PropertyControlContext_Impl::processEvent (this=0x391f3c0, _rEvent=...)
    at /home/master/src/libreoffice/workdirs/master/extensions/source/propctrlr/browserlistbox.cxx:315
#8  0x00007f0e3c790d86 in comphelper::AsyncEventNotifier::execute (this=0x34db400)
    at /home/master/src/libreoffice/workdirs/master/comphelper/source/misc/asyncnotification.cxx:221
#9  0x00007f0e3b9d9a58 in salhelper::Thread::run (this=0x34db400)
    at /home/master/src/libreoffice/workdirs/master/salhelper/source/thread.cxx:40
#10 0x00007f0e3b9d9e2d in osl::threadFunc (param=0x34db410) at /home/master/src/libreoffice/workdirs/master/include/osl/thread.hxx:187
#11 0x00007f0e3e06f79f in osl_thread_start_Impl (pData=0x34d9740) at /home/master/src/libreoffice/workdirs/master/sal/osl/unx/thread.c:251
#12 0x00007f0e3d798e0e in start_thread (arg=0x7f0e0e6b4700) at pthread_create.c:311
#13 0x00007f0e3da9595d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113



The m_aValues itself comes from rptui::GeometryHandler::getConstantValue; file reportdesign/source/ui/inspection/GeometryHandler.cxx, starting line 940 (in master):

  ::std::vector< OUString > aList;
  tools::StringListResource aRes(ModuleRes(_nResId),aList);
  uno::Sequence< OUString > aSeq(aList.size());
  ::std::copy( aList.begin(), aList.end(), aSeq.getArray() );

which is then passed to com::sun::star::inspection::StringRepresentation::createConstant, which sticks it in the third element of the rArguments argument to stoc_smgr::OServiceManagerWrapper::createInstanceWithArgumentsAndContext which in turns calls cppuhelper::ServiceManager::createInstanceWithArgumentsAndContext which ends up in cppu::OSingleFactoryHelper::createInstanceWithArgumentsAndContext, which passes the arguments array to pcr::StringRepresentation::initialize, which sticks the third element in m_aValues.
Comment 8 Commit Notification 2013-08-19 12:24:22 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "master":

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

fdo#67109: Order of XConstantsTypeDescription.getConstants is unspecified



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 9 Stephan Bergmann 2013-08-19 13:30:50 UTC
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=def066bb6559e8c77eeb924db1356f9848f5c8a2> "fdo#67109: Order of XConstantsTypeDescription.getConstants is unspecified": "...it looks like it used to be the order the constants appeared in the .idl file, while now it happens to be the lexicographical order of the constant's names.  For all the constant groups in com.sun.star.report the order expected by the code appears to be the order of the constant's numeric values (which happens to coincide with the order of appearance in the .idl files), so explicitly sort them that way."

I found no other uses of XConstantsTypeDescription.getConstants on master that made a similar assumption about order.
Comment 10 Stephan Bergmann 2013-08-19 14:15:04 UTC
requested backports to libreoffice-4-1 (<https://gerrit.libreoffice.org/#/c/5512/>) and libreoffice-4-1-1 (<https://gerrit.libreoffice.org/#/c/5513/>)
Comment 11 Commit Notification 2013-08-19 14:51:34 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "libreoffice-4-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=90826f5ee457449d78608e00bf05be412a86faf4&h=libreoffice-4-1

fdo#67109: Order of XConstantsTypeDescription.getConstants is unspecified


It will be available in LibreOffice 4.1.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 12 Commit Notification 2013-08-19 17:56:57 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "libreoffice-4-1-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6c17704810cbd8b937abaa915ef89c89337f713d&h=libreoffice-4-1-1

fdo#67109: Order of XConstantsTypeDescription.getConstants is unspecified


It will be available already in LibreOffice 4.1.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 13 pierre-yves samyn 2013-09-09 07:33:58 UTC
Hello

WORKSFORME with Version: 4.1.2.1
Build ID: bf15ac65c2167fb1ef3daf3710609d4a4c369a9

Thank you :)

Regards
Pierre-Yves