These are actually two somewhat different regressions originating from the same commit. I'm reporting both here, but can split one off if it's more feasible. 1. - Type some text in an empty document. - Enable 'Protect form' Writer compatibility setting. - Try typing some more text in the document. => Typing is possible. The document should be protected and uneditable (apart from filling in forms). After saving it in DOC(X) format, and reloading it, the document is protected since the fresh fix to bug 123912 comment 2, but it should become protected right away. 2. - Open attachment 149778 [details] from bug 123912, which contains a single drop-down form field, and is form-protected. - Position cursor before the dropdown, and press Enter to insert a line break. - Move the cursor up, and start typing. => This specific typing is possible, while no typing should be possible. Both of these regressions were introduced by the following commit. Adding Cc: to Serge Krot, please take a look. https://cgit.freedesktop.org/libreoffice/core/commit/?id=0898595532d1e3f498c259b6dfee462249b00667 author Serge Krot <Serge.Krot@cib.de> 2018-12-17 17:07:23 +0100 committer Thorsten Behrens <Thorsten.Behrens@CIB.de> 2018-12-20 15:16:34 +0100 sw: DOCX: allow editing of unprotected areas in protected doc
verified that the bisect and reproduction steps are correct.
Created attachment 150730 [details] sectionComparison.doc: attempt to document LO/MS implementations of sections With comment 0's patch, Protect Forms basically became meaningless. After some testing, I think that is OK. People designing Forms in LO should just use LO's native section protection capabilities. That should export / import OK to MS formats now.
(In reply to Justin L from comment #2) > With comment 0's patch, Protect Forms basically became meaningless. After > some testing, I think that is OK. Probably the label should be changed to "Protect Forms (depricated - create write-protected sections instead)"
(In reply to Justin L from comment #3) > Probably the label should be changed to "Protect Forms (depricated - create > write-protected sections instead)" see https://gerrit.libreoffice.org/71716 revert tdf#123912 ww8 export: re-protect implicit section
(In reply to Aron Budea from comment #0) > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=0898595532d1e3f498c259b6dfee462249b00667 > author Serge Krot <Serge.Krot@cib.de> 2018-12-17 17:07:23 +0100 > sw: DOCX: allow editing of unprotected areas in protected doc A bit of sleuthing discovered that this is tied to bug 122201.
(In reply to Aron Budea from comment #0) > 1. > After saving it in DOC(X) format, and reloading it, the document is > protected since the fresh fix to bug 123912 comment 2, but it should become > protected right away. The change of #1 was intended, and the mentioned fix has been reverted, so the document is always unprotected now. So ignore this part of the bug report. > 2. > - Open attachment 149778 [details] from bug 123912, which contains a single > drop-down form field, and is form-protected. > - Position cursor before the dropdown, and press Enter to insert a line > break. > - Move the cursor up, and start typing. > > => This specific typing is possible, while no typing should be possible. This could still be considered a minor bug. Changed the subject to focus on this part of the report.
Dear Aron Budea, 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://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
Problem #2 is not reproducible in LO 6.4 Version: 6.4.0.1 Build ID: 1b6477b31f0334bd8620a96f0aeeb449b587be9f CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded
Fixed in LO 6.3 actually, with commit c5c425296debb2fbd67af8ec29f87e285d08575f Author: Justin Luth on Tue May 7 09:38:19 2019 +0300 tdf#125151 sw: allow protection around field marks Similar to bug 105625, the cursor should be considered outside of a fieldmark when it is at the start. A delete at the start would normally delete the entire form field, but in this case the section is supposed to be protected, so deleting should be forbidden. This atStart situation is already looked for when the document is not protected. However, when the section is already protected, then a different code path is followed, and there the start position was ignored and thus became an editable part of the page, allowing the user to easily delete the field by mistake. An Alt-Enter is still possible at the beginning, but that was already true long before any of the patches discussed here. (I seem to remember a bug report about this anyway - that you can create it but can't delete it.) In any case, mark this particular bug as fixed. *** This bug has been marked as a duplicate of bug 125151 ***