This bug was filed from the crash reporting server and is br-e89335f6-0bff-4696-a95d-2d3a65291e53. ========================================= Version: 7.2.5.2 (x64) / LibreOffice Community Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: threaded ========================================= Crash in Windows 10 64bit while saving in fileformat "Excel 97-2003" into a Cryptomator vault (version 1.5.13) stored in a NextCloud storage space (NextCloud Client Version 3.1.3). Tabular should have some a single choice "radio buttons" working as XOR user options... What happend: if no Group-Field was used and saving as xls, users which use MS Excel or LibreOffice see radio buttons with "broken logic" after reopening the file = you cannot change your choice. if no Group-Field was used and saving as xlsx, users which use MS Excel cannot see the singele choice buttons. But if I store as ods file without a Group-Field the single choice options work. Inserting a Group-Field which should contain the singele choice "radio buttons" as "XOR Options" and save as xls above crash happens. Expected behavior: Single Choice behavior should work if xls, xlsx or ods file format is used for storing and no crash should happen while storing. Broken logic of single choice radio buttons maybe related some how to bug FORMCONTROLS: List Box "Linked cell" https://bugs.documentfoundation.org/show_bug.cgi?id=113584 logic bug of single choice buttons can verify with LibreOffice 6.3.4.2 (x64) and 7.2.5.2 (x64) I could not remember anymore which LibreOffice (version 4 or 5) could create single choices radio buttons which works in MS Excel correctly.
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
Created attachment 178694 [details] converted ODS to XLS and XLSX - compared view with LibreOffice and Excel converted ODS (without group field) to XLS and XLSX - compared view with LibreOffice and Excel
Created attachment 178695 [details] ZIP-File containing ODS and converted to XLS, XLSX and repaired versions from MSOffice ZIP-File containing ODS and converted to XLS, XLSX and repaired versions from MSOffice while creating this bundle I noticed that MSOffice Excel counts valures of "Single Choice" radio buttons beginning with value 1.
> if no Group-Field was used and saving as xls, users which use MS Excel > see radio buttons with "broken logic" after reopening the file = you > cannot change your choice. > if no Group-Field was used and saving as xlsx, users which use MS Excel > cannot see the singele choice buttons. This behavior of current LibreOffice Version: 7.2.5.2 (x64) / LibreOffice Community Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: threaded can be reproduce under an old linux VM with an old LibreOffice Version: 4.2.8.2 Build-ID: 420m0(Build:2) So the problem is independent of operating system under which the ODS file is converted to XLS or XLSX.
(In reply to Robert_Hartmann from comment #4) [...] > can be reproduce under an old linux VM with an old LibreOffice > Version: 4.2.8.2 > Build-ID: 420m0(Build:2) > > So the problem is independent of operating system under which the ODS file > is converted to XLS or XLSX. And I can reproduce broken single choice radio buttons with portable LibreOffice Calc 3.3.0: - broken logic in XLS after reopening in MS Excel - broken graphic element in XLSX after reopening in MS Excel : Excel message is "Reparierte Datensätze: Zeichnung von /xl/drawings/drawing1.xml-Part Zeichnungsform)" which is german for "reparing data drawing /xl/drawings/drawing1.xml-Part" after "reparing step" radioboxes are missing. In comment #0 I said: > I could not remember anymore which LibreOffice (version 4 or 5) > could create single choices radio buttons which works in MS Excel correctly. Well I now tested one Version 3.x, one Version 4.x , one Version 6.x and current Version 7.2.5.2 ... may be one Version 5.x worked or I didn't remember correctly ... or it was an OpenOffice version before I switched to LibreOffice which created correct Single Choice Radio Buttons ...
(In reply to Robert_Hartmann from comment #5) > Well I now tested one Version 3.x, one Version 4.x , one Version 6.x and > current Version 7.2.5.2 ... may be one Version 5.x worked or I didn't > remember correctly ... or it was an OpenOffice version before I switched to > LibreOffice which created correct Single Choice Radio Buttons ... I found an very old bug report from 2004 for OpenOffice ( https://bz.apache.org/ooo/show_bug.cgi?id=30823 ) , where broken grouped single and multiple choice radio buttons where discussed. That bug report contains some patches. The latest comment from year 2013 in that bugreport mentioned, that with Apache OpenOffice 4.0.0 (and AOO 3.4.0) the problem where gone. Just to complete my Single Choice Bugreport with a next test: Now I opened the ODS-File created with Libre Office 7 with the current portable Version of Apache OpenOffice 4.1.11 - AOO4111m1(Build:9808) - Rev. bdb20b2a64 2021-09-20 16:18 : This time the ODS-File is visualised like the XLS (LibreOffice Calc export) in Excel, that means no choice change is possible more than one time in ODS opened by OpenOffice. Next try : Creating in OpenOffice 4.1.11 a Single Choice File and open it in Libre Office 7.2.5.2 works as expected. Exports from OpenOffice to XLS seems to have the same problem like LibreOffice export to XLS : After saving choosing logik is broken. I think the grouping part is missing after export to XLS.
Quoting a message from 2005-11-14 ( https://bz.apache.org/ooo/show_bug.cgi?id=57857#c3 ) : > There are two kinds of option buttons in Excel: > > - Old form controls from MSOffice 5.0/95: If linked to a cell, the cell refers to the > entire group and will contain the 1-based index of the selected option button or 0, if > no button is selected initially (even in a group; a single option button is just a > special case of a group). > > - New ActiveX form controls (MS Forms 2.0): If linked to a cell, the cell will contain > TRUE/FALSE for exactly one option button (not linked to the group). > > Anyway, the Excel filters lose grouping information for option buttons. > This is already addressed in issue https://bz.apache.org/ooo/show_bug.cgi?id=30823 . From my point of view "loosing grouping information" for "option buttons" = "single choice radio buttons" = "xor-choice buttons" while saving to Excel-file-formates is true for LibreOffice (and OpenOffice) with current versions in year 2022. And if you open a xls, xlsx created with MS Excel containing grouped or ungrouped single choice radio buttons with LibreOffice Calc, change some choice and store it again, than in Excel and LibreOffice the choose-logic is broken (grouping information was lost while saving).
Multiple problems here while rule is: One issue per bug. 1. as for crash, I don't repro, and it may be about NextCloud specifix conf - bug only makes sense if reproducible so please write steps to reproduce, otherwise your crash report will be of use in statistics if some crash happens in new versions. 2. repro save as XLS wrong and as XLSX differently wrong, when reopened both in LO and MSO - but it seems like a duplicate of bug 136397. Please clarify.
There's also Bug 79542 for XLS.
(In reply to Timur from comment #8) > Multiple problems here while rule is: One issue per bug. Well, it depends on definition, of the word "problem". I have one problem : I cannot save the single choice radiobuttons for interaction with excel-users. But if you say, hey there are multiple reasons for your problem, then you are right. But for me, all reasons have to be fixed to solve that one problem. As a programmer I do not like to force users to splitt their observations about reasons into multiple user reports, because for the user it is only one problem, one issue. To be fair, technical different reasons could fixed seperate, but the user issue remains until all reasons have a solution. > 1. as for crash, I don't repro, and it may be about NextCloud specifix > conf - bug only makes sense if reproducible so please write steps to > reproduce, otherwise your crash report will be of use in statistics > if some crash happens in new versions. The steps where clear: a) Open LO b) create two radio option buttons c) link their data with a cell d) put them in a group , that is set "group name" value f) store the file as XLS-File into a Cryptomator vault (cryptomator.org) living on a Nextcloud storage. g) crash while saving. Even if the crash is hard to reproduce, the crash reporting service had captured the crash, so there is an up to now uncovered problem. I could not find this signature with searching on bugreporting website. And I didn't find your linked bug reports via website. > 2. repro save as XLS wrong and as XLSX differently wrong, > when reopened both in LO and MSO > - but it seems like a duplicate of bug 136397. Yes, the bug 136397 from 2020-09-02 handles XLSX - but if it is technical the same reason, I do not know, but I think so. (In reply to Timur from comment #9) > There's also Bug 79542 for XLS Yes, the bug 79542 from 2014-06-02 handles XLS - but if it is technical the same reason, I do not know, but I think so. Perhaps the stack trace of crash gives information about where grouping or choosing-logic get lost.
Created attachment 178819 [details] Screenshot crash message : reproducible Crash is reproducible at my side: https://crashreport.libreoffice.org/stats/crash_details/32505920-be0c-47f5-bd7c-c03b5a7670c2 https://crashreport.libreoffice.org/stats/crash_details/7b65f2d1-1aae-458e-a518-4b6b497e93e3 But Webpage say: Not Found - The requested resource was not found on this server. So here a screenshot from crash catcher
(In reply to Robert_Hartmann from comment #10) > The steps to reproduce crash where clear: > a) Open LO > b) create two radio option buttons > c) link their data with a cell > d) put them in a group , that is set "group name" value > f) store the file as XLS-File into a Cryptomator vault (cryptomator.org) > living on a Nextcloud storage. > g) crash while saving. > > Well, I forget some steps between (d) and (f) and after (f) d) put them in a group , that is set "group name" value d.1) choose an option and switch to the other one. f) store the file as XLS-File into a Cryptomator vault (cryptomator.org) living on a Nextcloud storage. f.1) reopen the file in LibreOffice f.2) repair grouping (open context menue of radio option buttons, go to "Steuerelement-Eigenschaften" (control element properties), fill in value for "Gruppenname" (group name)) f.3) switch between chosen radio bottons f.4) save an crash
Should I fill the bugreport metadata - "keywords" with dataLoss, filter:xls, filter:xlsx, filter:ods - "see" with XLSX bug 136397 from 2020-09-02 and XLS bug 79542 from 2014-06-02 so that the reason "crash" can handle in this bugreport and other reasons "broken import/export" can handle in the other bugreports?
All first 10 entries of stack trace from catched crashes https://crashreport.libreoffice.org/stats/crash_details/e89335f6-0bff-4696-a95d-2d3a65291e53 https://crashreport.libreoffice.org/stats/crash_details/32505920-be0c-47f5-bd7c-c03b5a7670c2 https://crashreport.libreoffice.org/stats/crash_details/7b65f2d1-1aae-458e-a518-4b6b497e93e3 are Crashing Thread Frame Module Signature Source 0 sclo.dll ScUnoListenerCalls::ExecuteAndClear() C:\cygwin64\home\buildslave\source\libo-core\sc\source\ui\unoobj\listenercalls.cxx:65 1 sclo.dll ScDocument::BroadcastUno(SfxHint const &) C:\cygwin64\home\buildslave\source\libo-core\sc\source\core\data\documen3.cxx:972 2 sclo.dll ScDocShell::SetDocumentModified() C:\cygwin64\home\buildslave\source\libo-core\sc\source\ui\docshell\docsh.cxx:2951 3 sclo.dll ScDocShellModificator::SetDocumentModified() C:\cygwin64\home\buildslave\source\libo-core\sc\source\ui\docshell\docsh.cxx:3244 4 sclo.dll ScDocFunc::SetValueCell(ScAddress const &,double,bool) C:\cygwin64\home\buildslave\source\libo-core\sc\source\ui\docshell\docfunc.cxx:884 5 sclo.dll ScCellObj::setValue(double) C:\cygwin64\home\buildslave\source\libo-core\sc\source\ui\unoobj\cellsuno.cxx:6184 6 sclo.dll calc::OCellValueBinding::setValue(com::sun::star::uno::Any const &) C:\cygwin64\home\buildslave\source\libo-core\sc\source\ui\unoobj\cellvaluebinding.cxx:294 7 mergedlo.dll frm::OBoundControlModel::transferControlValueToExternal(frm::ControlModelLock &) C:\cygwin64\home\buildslave\source\libo-core\forms\source\component\FormComponent.cxx:2560 8 mergedlo.dll frm::OBoundControlModel::_propertyChanged(com::sun::star::beans::PropertyChangeEvent const &) C:\cygwin64\home\buildslave\source\libo-core\forms\source\component\FormComponent.cxx:1406 9 mergedlo.dll frm::ORadioButtonModel::_propertyChanged(com::sun::star::beans::PropertyChangeEvent const &) C:\cygwin64\home\buildslave\source\libo-core\forms\source\component\RadioButton.cxx:333
is this a place of current source files: https://cgit.freedesktop.org/libreoffice/core/tree/forms/source/component/RadioButton.cxx?id=3099c70b11c7e5b80fe4dbe3dc99171fb38c6fc2 There in line 346 there is the comment: // If my status has changed to 'checked', I have to reset all my siblings, which are in the same group as I am Assume that group information gets broken while saving to XLS / XLSX or reloading than an other choice radio button cannot reset the siblings, because they are some how "unknown". My guess is, that on my side, after reload "broken" file to repaire grouping information of radio buttons (that is editing group names beeing the same), code like this (see line 352) has been used: else if ( _rEvent.PropertyName == PROPERTY_GROUP_NAME ) And here is the comment from line 355: // Can't call OReferenceValueComponent::_propertyChanged(), as it // doesn't know what to do with the GroupName property. And than while saving file again, some thing goes hardly wron and LO crashs. If I had not find the right repository for current source code, where can I find it?
Created attachment 178848 [details] crash reproducible with LibreOfficeDev_7.3.3.0.0_Win_x64 I can reproduce the crash with LibreOfficeDev_7.3.3.0.0_Win_x64 Version: 7.3.3.0.0+ (x64) / LibreOffice Community Build ID: 08a9d2d250e041c3a6e7f7570cd2d6964dd96182 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: threaded But this time I only need 5 Steps. Attached Zipfile contains screenshots for every step: step1_reopen_saved_singleChoice.jpg step2_open_properties.jpg step3_edit_properties.jpg step4_click_radiobutton_no.jpg step5_click_radiobutton_yes_crash.jpg test_NoGroupField_produced_with_Excel.xls test_NoGroupField_LO_saved_firsttime.xls Crash happen if you open test_NoGroupField_produced_with_Excel.xls in LO store it and reopen it and doing above mentioned 5 steps. Crash happen too, if you open test_NoGroupField_LO_saved_firsttime.xls and doing above mentioned 5 steps. As you see in step5_click_radiobutton_yes_crash.jpg the crash catcher didn't mentioned a crashID therefor I cannot give you the URL.
(In reply to Robert_Hartmann from comment #16) > I can reproduce the crash with LibreOfficeDev_7.3.3.0.0_Win_x64 > [...] > But this time I only need 5 Steps. And with LibreOfficeDev_7.3.3.0.0_Win_x64 the crash is not related to Cryptomator or Nextcloud, because I had stored the XLS file plain on normal harddisk.
(In reply to Robert_Hartmann from comment #17) > (In reply to Robert_Hartmann from comment #16) > > > I can reproduce the crash with LibreOfficeDev_7.3.3.0.0_Win_x64 > > > [...] > > But this time I only need 5 Steps. > > And with LibreOfficeDev_7.3.3.0.0_Win_x64 the crash is not related to > Cryptomator or Nextcloud, because I had stored the XLS file plain on normal > harddisk. Please, attach it here
(In reply to Xisco Faulí from comment #18) > (In reply to Robert_Hartmann from comment #17) > > (In reply to Robert_Hartmann from comment #16) > > > > > I can reproduce the crash with LibreOfficeDev_7.3.3.0.0_Win_x64 > > > > > [...] > > > But this time I only need 5 Steps. > > > > And with LibreOfficeDev_7.3.3.0.0_Win_x64 the crash is not related to > > Cryptomator or Nextcloud, because I had stored the XLS file plain on normal > > harddisk. > > Please, attach it here The XLS is attached inside the zipfile together with screenshots, see attachment 178848 [details] Or do you mean, that I shouldn't put the XLS into the zip file?
Changed status to "NEEDINFO" because I need an answer from Xisco Faulí to my question to Xisco Faulí , see: https://bugs.documentfoundation.org/show_bug.cgi?id=147822#c19
[Automated Action] NeedInfo-To-Unconfirmed
I confirm the crash with Lo 7.4+ per steps in Comment 16. But, since steps are not clearly written, I write again: 1. Open zip attachment 178848 [details] 2. open test_NoGroupField_produced_with_Excel.xls 3. save as XLS and reopen 4. go to Design mode 5. select radio group and open Control Properties 6. see Name and Group name empty (bug 79542), fill them and close Properties 7. turn off Design mode 8. click radio No 9. click radio Yes > crash
LO 4.0 couldn't click No-Yes, LO 5.0 would crash on Design mode off, repro LO 6.0. Windows and Linux.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7a0a0e23b7e81c1ee0601824a4ee990a2178f98b Resolves: tdf#147822 ScUnoListenerEntry container must be std::list It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Pending review https://gerrit.libreoffice.org/c/core/+/136023 for 7-3
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/b137bbe994cf5b23128c27fc65866406c32bec8b Resolves: tdf#147822 ScUnoListenerEntry container must be std::list It will be available in 7.4.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/0750bc969ac515fb9390f02ddcaa022c846f2d8a Resolves: tdf#147822 ScUnoListenerEntry container must be std::list It will be available in 7.3.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thanks Robert for bring persistent until steps were clear. Many thanks to Eike for the fix.