Steps to reproduce: 1) Write some text. 2) Add a comment but don't write text into it. 3) Click to another position in the document. Expected behavior: - The created comment persists. Current behavior: - The created comment is deleted. This operation can be reverted by "undo". It is possible that this is intended behavior but: 1) It is not documented and thus unexpected by users. 2) The possibility to revert it is inconsistent with it.
sorry I don't understand... what's the purpose of an empty comment without any text inside? why an empty comment should persist?
I don't say that empty comment should persist. But if they don't persist then: - It should be probably noted in the user help. - Empty comments should not be re-createable using "undo". The current state is inconsistent because empty comment don't persists but they can be re-created later using "undo".
undo just reopens the comment window it's a step back in the last action which indeed was "open new comment" so I don't find that inconsistent
It doesn't just reopen the comment window. The text cursor is in the page text after this operation (and not in the comment). It allows to leave the comment empty. This is clear inconsistency.
(In reply to comment #4) > It doesn't just reopen the comment window. The text cursor is in the page > text after this operation (and not in the comment). It allows to leave the > comment empty. This is clear inconsistency. Good point! And this empty comment persists on saving and reopening the document. Set to NEW. Expected behavior: when undoing the cursor should be set in the comment window and leaving again without typing text in comment should make it removed. Best regards. JBF
this is a very "corner case" bug. it's still reproducible with LibO 4.2.5.2 and 4.4.0.0.alpha0+ Build ID: b9dca968c6fd0ab5ca140c65b0e54d153cd34986 TinderBox: Win-x86@42, Branch:master, Time: 2014-07-18_22:51:20
edited summary notes. I don't know which would be the more consistent behaviour... 1- leave empty comment on the page after moving cursor back to document, allowing user to edit in a second time 2- don't allow "undo" recreation of empty comments probably I see a scenario for "1" ... let's sat a user wants to insert a comment but before writing inside it, he decides to copy something in the document and paste it in the comment yellow tab. the automatic deletion of the empty comments will force him or to insert a new comment or to undo and move cursor inside the yellow tab
** 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.0.5 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: 2015-09-03
As it is described in comment #5 the bug is still reproducible with version 5.0.3.0+. Best regards. JBF
It still persists in 5.2.1.
** 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 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
Dear Lukas Jelinek, 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
Still reproducible in Version : 6.4.5.0.0+ Build ID : b52d304969a15e00d82745f4d2f96c04f188eb97 Threads CPU : 4; OS : Linux 4.15; UI Render : par défaut; VCL: gtk3; Ubuntu_18.04_x86-64 Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR Calc: threaded Best regards. JBF
*** Bug 134825 has been marked as a duplicate of this bug. ***
The fact that with Undo, you can reach a state which you normally can't, this is obviously a bug. The other part of the topic is how empty comment boxes should be handled. I admit it is surprising the first time and slightly annoying even after that but there is an easy work-around for this. I put an easy-to-recognise text into the newly created comment box. For example, two asterisks (**). After this, I go to the other place/application, put the content to the clipboard and when I come back, Ctrl-Z and Ctrl-V does the job (to delete the entered asterisks and paste the clipboard content). I personally don't mind if the current behaviour gets changed and instead of auto-deleting empty comments, a manual deletion will be required but I can work with the current workaround quite well.
To summarize bug 134825: + consistency is prime, user should always be in charge (Telesto) + keep the object when created newly but remove when content has been deleted (Heiko)