Description: After Editing NEW XML Form Document then closing it Writer (LO7.2) does not allow deleting a control for example on reopening the document. Workarounds in earlier versions speak of a Tools>Options>LibreOffice Writer>Compatibility flag to switch off but my LO7.2 does not have Tools>Options>LibreOffice Writer. Steps to Reproduce: 1. Open New XML Form Document 2. Use Design Mode to add a widget such as Text Control 3. Add a small instanceData XML nodeset fragment to the default Model 4. Tap on a leaf node of that nodeset to create a Binding 5. Edit the TextControl in design mode and add the Binding to its Data property 6. Save the document and exit from Libre Office. 7. Reopen the Document, highlight the TextControl in Design Mode and press keyboard [Delete], and the Read-Only Write-protected edit block comes up Actual Results: 1.This happened with LO 7.2.4.1 2.I upgraded to LO 7.2.5.2 but the behavior remains the same Expected Results: I expect to edit the document further but it will not allow that. Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: XMLFormDocument [Information guessed from browser] OS: Linux (All) OS is 64bit: yes
Created attachment 178604 [details] A copy of the now Read-only Write-protected XML Form document as described The file attached raises the Read-only Write-protect block when trying to -for example - delete the text control widget created as I describe in this report.
Created attachment 178605 [details] The blocked edit when trying to edit the attached XML Form document Then blocked edit warning
Created attachment 178606 [details] No Tools>Options>LibreOffice Writer>Compatibility Flag to turn off Earlier version apparently could turn of write-protection via an option flag that is not available in LibreOffice 7.x
Created attachment 178607 [details] The 7.2.5.2 LibreOffice Build on AMD64 CentOS 8 It is not clear if this is merely a missing UI flag that used to be turned off via UI options flag or whether it is a missing Configuration Option piece specific to the Linux CentOS 8 Build.
Please test with a clean profile, Menu/Help/Restart in Safe Mode
Attempting to load the ODT uploaded by the original poster causes Version: 7.2.5.2 / LibreOffice Community Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5 CPU threads: 8; OS: Mac OS X 12.2.1; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded to hang (spinning beachball), requiring forced kill, on macOS Macbook Pro M1 I've attached the trace provided by the Apple Crash Reporter.
Created attachment 178631 [details] Apple Crash Trace when loading ODT file
The hang occurs as soon as I click on the field to try and select it.
When testing with Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: beb6c62e990599d91ac5d9183164c94d269027d3 CPU threads: 8; OS: Mac OS X 10.16; UI render: Skia/Metal; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded there is no hang, and I can enter the text box field and enter some text. However, as reported by the OP, if I enter Form Design mode, and select the field control and try to delete it, I get the error message indicated by the OP. In the Properties dialog of the Writer file when loaded in LO, the security options are not set for the option "Open file read only".
Note that, using a workaround, the textbox control can be deleted via the Form Navigator : Bring up the Form Navigator. Right-mouse button click on TextBox 1 entry in the tree and choose Delete. Also note that no new controls can be added via Form Design toolbar.
Attempting to open the ODT file in Version: 7.1.8.1 / LibreOffice Community Build ID: e1f30c802c3269a1d052614453f260e49458c82c CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded leads to an instant and repeatable cycle of crash / empty recovery dialog.
Attempting to load the ODT in Collabora Productivity Version: 21.06.15.1 Build ID: 60a66e4bf6afbf5d4221dab436bb1aca744a7ddf CPU threads: 8; OS: Mac OS X 12.2.1; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded leads to same cycle of crash, and obligatory restart (despite the error message saying the office process will be automatically restarted, Collabora Office fails to restart, and needs to be restarted manually).
Testing with Version : 6.4.6.1 Build ID : 985dd72ca280d5c6da2e9f90f7ff9286cafe7ff8 Threads CPU : 8; OS : Mac OS X 10.16; UI Render : par défaut; VCL: osx; Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR Calc: threaded I can select the textbox control in Form Design mode, and although I can't delete the control with the mouse and backspace key, if I use the context menu, I can choose "Cut" to remove the control from the document. Seems like a regression to me.
Re: Comment # 5 - I did restart LO in safe mode and continued into safe mode at the awareness prompt / reminder; On opening the sample XML Form document (TourDeForce.odt) LO persisted with Read-only Write-protected edit block. Thnx
Don't know why this one has been set to NEW. I have downloaded first attachment, set the form in Design-Mode (Form → Design-Mode | also available in Form Control bar) and could delete or change controls as I want. A form will be opened for input data, if it is opened again after first form design. So you have to switch to Design Mode. Writer isn't available for set any option if I only open a XML Form Document. I have to open a Writer document to set options here. So this option should have nothing to do with XML Form Document.
*** Bug 133961 has been marked as a duplicate of this bug. ***
Testing the ODT against Version: 7.5.1.2 (AARCH64) / LibreOffice Community Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129 CPU threads: 8; OS: Mac OS X 13.2.1; UI render: Skia/Raster; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded I still can't delete the Form control in design mode easily. At least LO doesn't crash any more. Attempt to delete the textbox control: 1) Load OP's originally posted ODT into Writer 2) Switch to Form Design mode 3) Select textbox control or the label with the mouse. 4) Press the Delete key (or Backspace, on macOS). 5) Error message saying that the Protected Content Can Not Be Modified. 6) Open the Form Navigator 7) Right mouse button click on "Text Box 1" entry, choose Delete from the context menu, text control is deleted. Bug still present for me, on macOS.
(In reply to Alex Thurgood from comment #17) > > I still can't delete the Form control in design mode easily. At least LO > doesn't crash any more. > Please see bug 154333. Its a little bit tricky to get the deign mode on since LO 7.3.6.2
(In reply to Robert Großkopf from comment #18) > (In reply to Alex Thurgood from comment #17) > > > > I still can't delete the Form control in design mode easily. At least LO > > doesn't crash any more. > > > Please see bug 154333. Its a little bit tricky to get the deign mode on > since LO 7.3.6.2 And another hint: It will only run through toolbar Form Design. Button for switching Design Mode On/Off seems to have different function to the buttons in Form → Design Mode and toolbar Form Controls. Use LO 7.3.6.2 or newer and this one will work.
On pc Debian x86-64 with master sources updated today or with LO Debian package 7.4.5.1, could you give a try to a recent LO version? (from 7.4 branch at least since 7.3 branch is EOL).
bibisected by executing steps mentioned in comment #17 bibisected in version: Version: 7.2.0.0.alpha1+ / LibreOffice Community Build ID: 556243467a0ac3f647de75bf3fb6c9f3b72466a4 CPU threads: 3; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: en-IN (en_IN); UI: en-US Calc: threaded repo: https://bibisect.libreoffice.org/linux-64-7.2.git-bundle commit 64b28ddde27a291801fab8f122dbc2c3a50dbc5c Author: Jenkins Build User <tdf@pollux.tdf> Date: Thu Nov 26 15:53:26 2020 +0100 source 38372ccbfd1c6380d8655364c39c55b99459ad34 source 38372ccbfd1c6380d8655364c39c55b99459ad34 instdir/program/setuprc | 2 +- instdir/program/versionrc | 2 +- instdir/share/registry/main.xcd | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) Addint CC: Christian Lohmaier (there were 2 matches, added both of them as i was not sure) author Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Sun Nov 22 14:57:49 2020 +0100 committer Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Sun Nov 22 14:57:49 2020 +0100 attached: bibisecting done in command line
Created attachment 186859 [details] bibisecting steps bibisecting notes: to locate in which 7.2 commit does swriter crashes while trying to delete the textbox control in file "TourDeForce.odt". while deleting textbox control error popup "Readonly content. Write protected content cannot be changed." appears -> repro -> bibisect mark as bad. used menu "Form" -> "Design Mode", select textbox control and pressed "delete" key bibisecting observations: a) general - oldest - swriter crashed - repeated "LibreOfficeDev 7.1 Document Recovery" popup while opening the "TourDeForce.odt" file b) general - master - repro c) between steps 6 and 5 - swriter crashed - repeated "LibreOfficeDev 7.2 Document Recovery" popup while opening the "TourDeForce.odt" file - bisect marked as bad. d) between steps 5 and 4 - swriter crashed - repeated "LibreOfficeDev 7.2 Document Recovery" popup while opening the "TourDeForce.odt" file - bisect marked as bad. e) between steps 4 and 3 - swriter crashed - repeated "LibreOfficeDev 7.2 Document Recovery" popup while opening the "TourDeForce.odt" file - bisect marked as bad. f) between steps 3 and 2 - swriter crashed - repeated "LibreOfficeDev 7.2 Document Recovery" popup while opening the "TourDeForce.odt" file - bisect marked as bad. g) between steps 2 and 1 - swriter crashed - repeated "LibreOfficeDev 7.2 Document Recovery" popup while opening the "TourDeForce.odt" file - bisect marked as bad. h) between steps 1 and 0 - swriter crashed - repeated "LibreOfficeDev 7.2 Document Recovery" popup while opening the "TourDeForce.odt" file - bisect marked as bad. i) between steps 0 and first bad commit - swriter crashed - repeated "LibreOfficeDev 7.2 Document Recovery" popup while opening the "TourDeForce.odt" file - bisect marked as bad. j) confirmation - checkout 64b28ddde27a291801fab8f122dbc2c3a50dbc5c - swriter crashed - repeated "LibreOfficeDev 7.2 Document Recovery" popup while opening the "TourDeForce.odt" file k) confirmation - HEAD^ - swriter crashed - repeated "LibreOfficeDev 7.2 Document Recovery" popup while opening the "TourDeForce.odt" file
bibisecting result is not correct, reverting
Does this bug really exist any more? Set the Design Mode on in LO 7.2.5.1 and the control couldn't be deleted. Tried the same in LO 7.3.6.2 and the control could be deleted. Same with all newer versions here. Reason seems to be: There are different Design Modes for Form → Design Mode and Design Mode in the form design toolbar since LO 7.3. The design mode in toolbar Form Design has tip help "Design Mode On/Off". You could press this and design mode in Form → Design Mode is also be set to on. But you could press Form → Design Mode off afterwords and "Design Mode On/Off" always is set 'On'. Both design modes have to be set 'On' to delete the form control.
(In reply to Julien Nabet from comment #20) > On pc Debian x86-64 with master sources updated today or with LO Debian > package 7.4.5.1, could you give a try to a recent LO version? (from 7.4 > branch at least since 7.3 branch is EOL). Just re reading this, I forgot the main part, "I don't reproduce this".
Dear Malome Khomo, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear Malome Khomo, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp