It is the same with Windows version
tested with 4.1.0.4 under Win764 bit and I can resize with no problem the comments. which missing squares do you refer? can you please attach a screenshot?
Created attachment 84845 [details] This is how it looks like - no squares at corners and centers of edges Mouse cursor is not changed to arrows at edges and comment cannot be resized
Ok, now I understand and I can reproduce. in 4.0.4 the "resize" corners are visible immediately after you create a new comment... so you can resize it while editing. in 4.1.0 those "resize" corners are invisible till you save the comment (press enter) and then reopen it again (right click menu -> show comment) and click on it. so basically you cannot resize while editing. adding REGRESSION keyword and Calc expert to CC list. modified summary notes as well.
Same on Mac OS X with version 4.1.1.2
The bug is still present in LibO version 4.1.2.3 (Windows XP SP3) A short video clip shows that "nothing happens" when trying to resize the comment box. http://youtu.be/8KpsRDPAy7k Not possible to tell when mouse buttons is clicked on thougth.
I do not get the problem when running Windows Vista - but I am running fairly old version of Office
Can we have a test document to test this?
Created attachment 90506 [details] test document - comment is in the first cell
The problem is since version 4.1
the problem still exists in 4.2
I confirm Comment 5 in version 4.1.5.3. Drives me insane! I run Win 7 Ultimate, 64-bit.
Thank you for your e-mail. I am out of the office and will return on 6th of March 2014. I will have no access to my e-mails during this time. If your e-mail requires urgent attention please e-mail service@taxback.com. Alternatively I will reply to your e-mail when I am back. Kind Regards, Peter Draganov ICT Systems Administrator Email: pdraganov@taxback.com Web: www.taxback.com Phone: +359 52 919190 Fax: +359 5268 6883 Mobile: +359 889 530589 Contact Us: Taxback.com is an ISO 9001 certified company with 25 offices in 20 countries. This email is confidential and intended solely for the use of the individual to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of taxback.com. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you have received this email in error please forward it to info@taxback.com.
Further to my original post I run Linux Mint and Windows Vista. The problem is present in both versions - and like others it drive me mad On 5 March 2014 17:33, <bugzilla-daemon@freedesktop.org> wrote: > *Comment # 12 <https://bugs.freedesktop.org/show_bug.cgi?id=68695#c12> > on bug 68695 <https://bugs.freedesktop.org/show_bug.cgi?id=68695> from > Peter Draganov <pdraganov@taxback.com> * > > Thank you for your e-mail. I am out of the office and will return on 6th of > March 2014. I will have no access to my e-mails during this time. > > If your e-mail requires urgent attention please e-mail service@taxback.com. > > Alternatively I will reply to your e-mail when I am back. > > Kind Regards, > Peter Draganov > ICT Systems Administrator > > Email: pdraganov@taxback.com Web: www.taxback.com Phone: +359 > 52 919190 > Fax: +359 5268 6883 Mobile: +359 889 530589 > > > Contact Us: Taxback.com is an ISO 9001 certified company with 25 offices in 20 > countries. > > This email is confidential and intended solely for the use of the individual to > whom it is addressed. Any views or opinions presented are solely those of the > author and do not necessarily represent those of taxback.com. If you are not > the intended recipient, be advised that you have received this email in error > and that any use, dissemination, forwarding, printing, or copying of this email > is strictly prohibited. If you have received this email in error please forward > it to info@taxback.com. > > ------------------------------ > You are receiving this mail because: > > - You are on the CC list for the bug. > >
I add Calc expert to CC list. maybe he can help.
I have discovered that in the Linux versio (have not yet tried Windows) If you select the cell, right click and Select "Show Comment" from the pull down menu, then click in the comment area the box points are displayed and the box resized. If the points are not displayed try clicking on the border. You can then right click on the selected cell and choose "hide comment" On 7 March 2014 05:43, <bugzilla-daemon@freedesktop.org> wrote: > tommy27 <barta@quipo.it> changed bug 68695<https://bugs.freedesktop.org/show_bug.cgi?id=68695> > What Removed Added CC markus.mohrhard@googlemail.com > > *Comment # 14 <https://bugs.freedesktop.org/show_bug.cgi?id=68695#c14> > on bug 68695 <https://bugs.freedesktop.org/show_bug.cgi?id=68695> from > tommy27 <barta@quipo.it> * > > I add Calc expert to CC list. maybe he can help. > > ------------------------------ > You are receiving this mail because: > > - You are on the CC list for the bug. > >
(In reply to comment #15) > I have discovered that in the Linux versio (have not yet tried Windows) If > you select the cell, right click and Select "Show Comment" from the pull > down menu, then click in the comment area the box points are displayed and > the box resized. If the points are not displayed try clicking on the > border. You can then right click on the selected cell and choose "hide > comment" > Thats right, but that are a way too much clicks if you are using comments a lot. Even it worked in a former version.
Version: 4.3.0.4 Build-ID: 62ad5818884a2fc2e5780dd45466868d41009ec0 Bug still exists. When you right click on the cell with the comment and select view comment then you can resize it. But in an older version you could resize the comment while editing it. This is way more comfortable and you would expect it to work that way. If I hadn't searched for it in bugzilla I would never thought of the option to view the comment and then to resize it. Please change that back so you can resize a comment while editing.
Bug continues to still exist and can confirm frustration. Linux Mint, Calc Version:4.2.7.2
*** Bug 90123 has been marked as a duplicate of this bug. ***
this bug is still there in 4.1.4.2, 4.2 and 4.3.6 both on Windows x86 and Linux x64
Not a really serious issue, but is very annoying.
So, everytime you want to resize a comment, it requires two extra steps (Show Comment, then close comment) unless you want the comment to remain on the screen, which most people do not. Not cool. (In reply to tommy27 from comment #3) > Ok, now I understand and I can reproduce. > > in 4.0.4 the "resize" corners are visible immediately after you create a new > comment... so you can resize it while editing. > > in 4.1.0 those "resize" corners are invisible till you save the comment > (press enter) and then reopen it again (right click menu -> show comment) > and click on it. so basically you cannot resize while editing. > > adding REGRESSION keyword and Calc expert to CC list. > modified summary notes as well.
regression as comment 3
*** Bug 93852 has been marked as a duplicate of this bug. ***
Bug still there, after over 2 years from original report, tested by me in 5.0.2.2 on Linux 64bit.
Migrating Whiteboard tags to Keywords: (bibisectRequest) [NinjaEdit]
Confirming that this bug still exists as of version 5.1.0.3 release. Issue is happening as described for me on Windows 10 Pro using the Windows x86_64 binary. Comment window can only be resized after you insert a comment, step off the cell then right click "Show Comment" then you can resize the comment field then you have to select "Hide Comment" to get it back to hover display. This bug requires a lot of extra clicks to work around. I haven't touched C code in 20 years so I don't think you want me mucking with anything. Anybody know the last version that this feature still worked properly? It might go a long way to cut down the amount of coding to fix.
As you can see in Comment 3, 4.0.4 was OK.
Regression introduced by author Armin Le Grand <alg@apache.org> 2013-05-02 16:29:07 (GMT) committer Caolán McNamara <caolanm@redhat.com> 2013-05-10 11:08:40 (GMT) commit 54a1feb9b9bd654774b9aa60cda7ef9a1cd11064 (patch) tree 2aefd9d1d8e0970f06d3623ea08c1b2734ee1285 parent a356da4e2adefd86d6f802c0753b3718909e4e4c (diff) Resolves: #i122142# use simple text hilight frames use simple text hilight frame when captions are in TextEdit mode (cherry picked from commit bdcd01c39324f5c74e0f696f2afc3449243e6c4b) Conflicts: svx/source/svdraw/svdmrkv.cxx svx/source/svdraw/svdorect.cxx Adding Cc: to Armin Le Grand
As https://bz.apache.org/ooo/show_bug.cgi?id=122142 explains it was an error to show the handles in captions when edit was active. To change this, bigger changes would have to be done on EditEngine (due to it painting directly and thus uncontrolled to the edit views). Reactivating this would lead to awful paint errors. Problem is more that comments at cells do not behave like the rest of draw objects: Normally pressing ESC leaves the edit mode, but keeps the object selected, pressing RETURN re-activates TextEdit. Thus I see more a problem in that SC immediately hides the caption when in edit mode and pressing ESC -> this should lead to the object being selected, the next ESC should hide it.
*** Bug 103887 has been marked as a duplicate of this bug. ***
*** Bug 83065 has been marked as a duplicate of this bug. ***
*** Bug 108451 has been marked as a duplicate of this bug. ***
** 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
The bug is still present in Windows version: 6.0.4.2 (x64)
*** Bug 119763 has been marked as a duplicate of this bug. ***
This is one of the bugs original filers. Will begin testing as requested. Will update upon completion.
Testing complete. Versions and testing environment: Package LibreOffice_6.1.1.1_Win_x64.msi on Microsoft Windows [Version 10.0.17134.228]. As of 9/9/2018 10:40am PDT, this issue is still present and unresolved. Ticket is still valid as is without further description of the issue. Reopening ticket to the floor.
Dear Peter Draganov, 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
Confirmed present in current version. Testing 3.3 now and will update based on results.
Confirmed bug did NOT exist in version 3.3. Confirmed regression. I don't have a full VM environment setup so I'm not up to confirming the version marked is the first version with the regression. Regression tag already set.
Oops. Forgot to say my current test version/environment. Version: 6.3.3.2 (Win x64)
I can confirm that the bug still exists in 6.2.8.2-2.fc30
*** Bug 133255 has been marked as a duplicate of this bug. ***
Thanks! This is still present in 7.0 alpha FYI...
and 7.0 b1. Just ran into this using Calc and it is quite frustrating to be unable to resize the comment then writing it and having to use the default format which may fit some but maybe not even the majority of comments. Interstingly, while the OP reports that the issue is limited, in 7.0b1 the problem exists also after the comment was created or the document re-opened. I can't find any way to resize the comment. So the issue has further regressed.
Confirmed, someone has mucked with this component in 7.0b1 and made it to where comment (and other related components) resizing that was a buggy two-step process is now *BROKEN* and not possible. Recommend increase in bug severity level for 7.0b1. This is not technically a regression as no previous version had this component completely non-functional. If beta developer is actually working on this bug, please comment on it. If no one caused this on purpose, recommend intentionally regress to 6.3.6 codebase for this component for 7.0b2 or 7.0rc1.
If next planned version was rc1, recommend delay RC release to fix component or regress codebase to 6.3.6 in this area. I'm fairly certain we'd get a lot of negative feedback if this is not corrected before RC.
Looks like 7.0b1 bug escalation was caused by a commit from Tomaž Vajngerl. Emailing the issue directly to him to see if he has the resources and time to resolve.
Yeah.. blame a commit that's not even in LO 7.0 branch.
Sorry, first time trying to go through them. Obviously, I mailed the wrong person. My apologies.
(In reply to David from comment #47) > Confirmed, someone has mucked with this component in 7.0b1 and made it to > where comment (and other related components) resizing that was a buggy > two-step process is now *BROKEN* and not possible. Recommend increase in > bug severity level for 7.0b1. This is not technically a regression as no > previous version had this component completely non-functional. If beta > developer is actually working on this bug, please comment on it. If no one > caused this on purpose, recommend intentionally regress to 6.3.6 codebase > for this component for 7.0b2 or 7.0rc1. Please create a new bug report..
(In reply to steve -_- from comment #46) > in 7.0b1 the problem exists also after the comment was created or the > document re-opened. I can't find any way to resize the comment. 7.1+ : cannot resize while editing, but possible with Show Comment. SO not cleat what's the exact change you refer to. (In reply to David from comment #47) > Confirmed, someone has mucked with this component in 7.0b1 and made it to > where comment (and other related components) resizing that was a buggy > two-step process is now *BROKEN* and not possible. If there was a change, just write exact new behavior, instead of additional talk . (In reply to Telesto from comment #52) > Please create a new bug report.. No need to make too many reports on the *same* issue of resizing comments. New report is for different issue, not the same issue that changed behavior. So far this is Minor severity but High importance for being regression with many CCed users and duplicates.
At the time your message appeared, I had already created the new bug as directed. New bug ID: 133696.
Do you want me to mark the new one a duplicate and point it back to here?
This "Show Comments" workaround stopped working, and no other workaround has been found on since the following: Version: 7.0.0.0.beta1 (x64) Build ID: 94f789cbb33335b4a511c319542c7bdc31ff3b3c CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL (Updated build info since bug changed.)
*** Bug 133696 has been marked as a duplicate of this bug. ***
I don't see that Show Comment stopped working and don't understand what changed. Needed are exact steps, better with screenshot with comments or Screencast.
Created attachment 161677 [details] Screenshots which show how small the comment box is and how complicated it is to resize it I copied over my attachment from bug #119763 which describes exactly the same problem. Read there (not much text) if you want to know more
Retested, macOS 10.15.5 Reproduce * open calc * add comment and keep writing until the writing goes beyond the space of the default comment size Currently Writing continues outside of the comment box. Expected Comment box should grow as users keep typing their comment and the comment exceeds the default comment box size. With 7.0b1 I no longer see the problem, that even with View > Comments the handles to resize an existing comment do not exist. They did show as expected in this second test. I will watch this and send an update if they go missing again for existing comments. So this is indeed the behavior described in the original report and no additional bad behavior is happening now.
Created attachment 165597 [details] Comment overflowing its box when Print Screen is pressed (Ubuntu 20) I'm running v7.0.0.3 and I still see several issues with long comments. 1. Pressing Print Screen displays the whole comment, but the comment overflows its box. This happens on Ubuntu 20. See attached screenshot.
Created attachment 165598 [details] Right clicking on a cell briefly displays it in its entirety (continued) 2. When mousing over a cell with a comment, the comment is displayed truncated, and there's no way to resize the comment box (when moving the mouse towards one of the edges of the comment box, the box disappears). But when right clicking the cell, the comment is displayed briefly, again overflowing its box. You can see this in the attached screencast, if you go frame-by-frame.
Created attachment 165599 [details] Sample spreadsheet with one cell with one comment (continued) 3. (Major) When editing a comment longer than its default box, the text below the box overflows and becomes hard to distinguish from the cells in the spreadsheet that it overlaps with, because the part below the default box is unstyled. It's also apparently impossible to drag the comment box to resize it.
For the record, the problem with the comment not being resized while typing is reported in bug 114956 and is a more recent regression. Do not mix them
*** Bug 141150 has been marked as a duplicate of this bug. ***
*** Bug 143492 has been marked as a duplicate of this bug. ***
This commit was developed for another code base, and not merged by me. For complex changes like this, side-effects are to be expected; sadly I dont't have the cycles to deal with all the fallout. Un-Ccing myself for the while.
There is a working workflow because you can easily show all comments (*). So you can easily resize any comment you want. With the fix of bug 114956 you see the whole text you are typing in the comment. According to comments #30 and #67 from Armin Le Grand, it seems it is a bad and risky idea to go back to the previous behavior. So closing as WontFix. (*) you can add a shortcut for the command "Show Comments" : menu Tools > Customize Best regards. JBF
No, this cannot be closed. Because bug is valid and there are many users who need it fixed. How to fix is another issue, wait for someone or make it into a tender bundle.
(In reply to Timur from comment #69) > No, this cannot be closed. Because bug is valid and there are many users who > need it fixed. How to fix is another issue, wait for someone or make it into > a tender bundle. WontFix does not mean the bug is not valid. But Since the bug has been reported the situation has changed due to the fix of bug 114956 and the need to be able to resize a comment while editing is now less strong than it was. and According the comments #30 and #67 from Armin Le Grand whose advice about the code should be listened to, the code modifications needed to restore previous behavior is risky and prone to weird side effects. So I think closing this bug report as WontFix would be a prudent decision. Best regards. JBF
Frankly, now I am not sure what the original bug report was. However, assuming that it was the "inability to resize a comment," I agree that the bug has been fixed because it is now possible to resize the comment box. Clunky, but possible. Agree that this bug report should be closed.
@larrybradley: As someone that's been following this thread since 2013, let me summarize the issue. The problem was to edit the size of the comment boxes was extremely clunky because you had to select 'Show Comment' in order to get the resizing boxes to appear. *Then*, an edit was made that removed *ALL* ability to resize the comments box. *Now*, we've come full circle and are back to the original issue. The debate seems to be, whether to say if it's too risky and time consuming to fix a bad UI issue since the problem that broke the functionality entirely have been resolved. But, as far as what the ticket is about, we've come fill circle to the original issue that led to this beg report. Aka, we're back where we started.
(In reply to David from comment #72) > @larrybradley: As someone that's been following this thread since 2013, let > me summarize the issue. The problem was to edit the size of the comment > boxes was extremely clunky because you had to select 'Show Comment' in order > to get the resizing boxes to appear. *Then*, an edit was made that removed > *ALL* ability to resize the comments box. *Now*, we've come full circle and > are back to the original issue. The debate seems to be, whether to say if > it's too risky and time consuming to fix a bad UI issue since the problem > that broke the functionality entirely have been resolved. But, as far as > what the ticket is about, we've come fill circle to the original issue that > led to this beg report. Aka, we're back where we started. Got it. As it stands today, I would leave it as-is, which means that I don't think it should have been a bug issue until after all ability to resize the comments box was removed. Now that it is back to its original state I don't view it as a bug. BTW, to edit a comment in Excel takes only one fewer keystroke. Personally, don't don't consider it to be a bug at this point, more of a (very minor) preference for the way things should work. Agree that it is not worth the time and effort…as long as the current functionality does not disappear.
Then would it make more sense to un-duplicate and reopen bug #68695 then, which talks about a specific usability/efficiency problem with the current UI/UX specifically when creating a new comment in a cell?
(In reply to Jean-François Fortin Tam from comment #74) > Then would it make more sense to un-duplicate and reopen bug #68695 then, > which talks about a specific usability/efficiency problem with the current > UI/UX specifically when creating a new comment in a cell? I, as one of the earlier submitters would agree that is a good course of action. This used to work properly until a change committed in version 4.1.0.4-release. And though, as earlier poster stated, it may only seem to be one extra step, but if you have to work with calc sheets with comments a lot (like I do), those extra steps require you to stop what you're doing an use the work-around, which shouldn't have to be done and we didn't have to do in OpenOffice or the earlier LibreOffice versions.
(In reply to David from comment #75) > (In reply to Jean-François Fortin Tam from comment #74) > > Then would it make more sense to un-duplicate and reopen bug #68695 then, > > which talks about a specific usability/efficiency problem with the current > > UI/UX specifically when creating a new comment in a cell? > > I, as one of the earlier submitters would agree that is a good course of > action. This used to work properly until a change committed in version > 4.1.0.4-release. And though, as earlier poster stated, it may only seem to > be one extra step, but if you have to work with calc sheets with comments a > lot (like I do), those extra steps require you to stop what you're doing an > use the work-around, which shouldn't have to be done and we didn't have to > do in OpenOffice or the earlier LibreOffice versions. Understood. Who makes the final call on this? I look forward to the resolution. You guys do good work. Thanks.
*** Bug 148804 has been marked as a duplicate of this bug. ***
should be able to re-size and re-position comment box while writing or editing that comment [like Excel does].....I still prefer Libre, but that comment re-sizing....
Yeah sorry folks, not to look a gift horse in the mouth, but it's ridiculous that this has not worked for so long
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/805abacd0d1fe2d5522a2041fc3c07961a62ba5f related tdf#68695 tdf#141136 sc: comment can't resize; avoid context change It will be available in 24.2.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.
comment 81 removes the OOo code that enabled comment resizing on insert. So it is a good code pointer, but needs to be re-worked as per comment 30. In no way is comment 81 expected to fix this bug report. I only included the number because of the close affiliation with OP's report.
*** Bug 155642 has been marked as a duplicate of this bug. ***