As the summary says, if a document with a input list field is saved as a .doc, the input list becomes completely read-only. It is still possible to open a popup with the choices and select a choice and the selected choice saves correctly (at least that's an improvement over OOo - read further), but it is not possible to edit the list of choices and more importantly, _there is even no way to delete the field_ as a whole. I have noticed this with 3.5, but it's the same with 3.4.5. I didn't test 3.3 or older 3.4 versions, but it _is_ possible to edit the field (in the same document) if opened in OOo 3.3 (as a downside OOo doesn't save the selected choice, the default value is always displayed after reopening). So it looks like the problem isn't with the file itself, but the way LO loads it. Note that re-saving to .odt doesn't fix this, the field is still read only. In the re-saved .odt, the list is stored as <field:fieldmark field:type="vnd.oasis.opendocument.field.FORMDROPDOWN" />, whereas the editable version is <text:drop-down />. As a side note, if a input list is set as a cross reference target, it is reported as lost after saving to .doc, but it resolves and displays correctly if the file is opened in OOo?
related to Bug 43569 - EDITING: Undeletable fields in converted MS Word document ... ?
Seems that way, looks like I have to better my search skills, feel free to dupe if you find it identical enough.
Created attachment 56601 [details] test .odt from 3.4.5 with field I tested with a .odt, that I created in 3.4.5 and converted that to .doc in various versions: 3.5.0RC3, 3.5.0RC1, 3.4.5, 3.3.4, 3.3.0 Findings: - in all versions the fields are read only - in 3.3.4 and 3.3.0 there is no selection visible, or kept when you make it. In OOo 3.3.0 the field in the .doc works as in an odt document I guess this is a side effect/consequence of the field import ability for Ms-word from field documents...
Hi, (In reply to comment #2) > Seems that way, looks like I have to better my search skills, Never to late to try that :-) But often it's not too easy. > feel free to dupe if you find it identical enough. No, I just think it may be related - not really the same.
Unused feature.
Tested with LO 4.4.0.0.beta1 (Win 8.1) The field is selectable if I click on it, but it is unvisible that this is a drop-down list field (no border, no arrow on the right).
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.4 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT: - Update the version field - Reply via email (please reply directly on the bug tracker) - Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-01-17
Writer Version: 5.1.4.2 Build ID: 1:5.1.4-0ubuntu1 CPU Threads: 8; OS Version: Linux 4.4; UI Render: default; Locale: en-AU (en_AU.UTF-8) I can reproduce the behaviour described, as well as other defects with the 'basic' controls. 1. New document 2. Add list control, add 2x list items 3. Add combo box control, add 2x list items 4. Add a radio control 5. Add a checkbox control 6. Save as Word 2003 document. You are warned that you are saving in a format which may not have all of the features 7. Close and reopen The resulting Word 2003 document: * Renders the list control in a way that you can no longer interact with it * Renders the combo box and lets you choose options; but there are no longer any controls to manage the object * Renders the checkbox, minus the label text * Renders the radio button control with label text - but no longer has a right click context menu appearing at all
Created attachment 126840 [details] Basic form fields opendocument test case
Created attachment 126841 [details] Resulting word document after conversion
Created attachment 126842 [details] Word document converted back to opendocument
Created attachment 126843 [details] Variant test case: Original ODT saved as docx A further variant: * Create open document as per above * Save as .docx * Reopen Expected: * Checkbox control is rendered with label * Radio control is rendered with label * List control is rendered with options * Combo control is rendered with options * All controls have a context menu that allows them to be manipulated Actual: * Only the combo control renders, as a dropdown. It has the correct options, but you cannot manipulate it. * No radio, checkbox or list control
I think the latter scenario is mostly Bug #50097 so might leave that to cover off the export form controls to .docx behaviours.
Repro 6.2+
Dear khagaroth, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
In 6.4 alpha1, when RT DOC opens with LO, field is not read-only, but doesn't look as it should, with dropdown arrow. But more importantly, when that saved DOC is open with MSO, there's no field. So bug stays open.
Dear khagaroth, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I'm going to close this bug report. Things have greatly improved in general. However, this bug report talks both about exporting to DOC and DOCX. I see some content controls, and some fieldmarks controls. So there is absolutely no focus whatsoever, and thus no point in keeping this open.