Bug 68695 - EDITING: Comments cannot be resized while editing - missing squares around the comment/note
Summary: EDITING: Comments cannot be resized while editing - missing squares around th...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.1.0.4 release
Hardware: Other All
: high minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
: 83065 90123 93852 103887 108451 119763 133255 133696 141150 143492 148804 (view as bug list)
Depends on:
Blocks: Calc-Comments
  Show dependency treegraph
 
Reported: 2013-08-29 07:50 UTC by Peter Draganov
Modified: 2022-04-26 19:46 UTC (History)
26 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
This is how it looks like - no squares at corners and centers of edges (54.00 KB, image/jpeg)
2013-08-29 14:20 UTC, Peter Draganov
Details
test document - comment is in the first cell (7.40 KB, application/vnd.oasis.opendocument.spreadsheet)
2013-12-09 11:53 UTC, Peter Draganov
Details
Screenshots which show how small the comment box is and how complicated it is to resize it (358.31 KB, image/png)
2020-06-06 10:41 UTC, Daniel
Details
Comment overflowing its box when Print Screen is pressed (Ubuntu 20) (61.30 KB, image/png)
2020-09-17 07:08 UTC, Dan Dascalescu
Details
Right clicking on a cell briefly displays it in its entirety (299.26 KB, image/gif)
2020-09-17 07:10 UTC, Dan Dascalescu
Details
Sample spreadsheet with one cell with one comment (15.05 KB, application/vnd.oasis.opendocument.spreadsheet)
2020-09-17 07:12 UTC, Dan Dascalescu
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Draganov 2013-08-29 07:50:30 UTC
It is the same with Windows version
Comment 1 tommy27 2013-08-29 13:01:02 UTC Comment hidden (obsolete)
Comment 2 Peter Draganov 2013-08-29 14:20:46 UTC
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
Comment 3 tommy27 2013-08-30 09:53:29 UTC
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.
Comment 4 trevor.jenkins 2013-09-12 08:18:28 UTC
Same on Mac OS X with version 4.1.1.2
Comment 5 Grobe 2013-10-15 18:38:10 UTC
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.
Comment 6 David 2013-12-08 11:10:15 UTC Comment hidden (obsolete)
Comment 7 retired 2013-12-09 11:23:47 UTC Comment hidden (obsolete)
Comment 8 Peter Draganov 2013-12-09 11:53:35 UTC
Created attachment 90506 [details]
test document - comment is in the first cell
Comment 9 Peter Draganov 2013-12-09 11:54:37 UTC
The problem is since version 4.1
Comment 10 Bug Reports 2014-02-05 12:44:39 UTC
the problem still exists in 4.2
Comment 11 RNL 2014-03-05 17:20:47 UTC
I confirm Comment 5 in version 4.1.5.3. Drives me insane! I run Win 7 Ultimate,  64-bit.
Comment 12 Peter Draganov 2014-03-05 17:33:01 UTC Comment hidden (no-value)
Comment 13 David 2014-03-06 14:14:15 UTC Comment hidden (obsolete)
Comment 14 tommy27 2014-03-07 05:43:06 UTC Comment hidden (obsolete)
Comment 15 David 2014-03-14 12:32:13 UTC Comment hidden (obsolete)
Comment 16 Bug Reports 2014-03-14 12:58:22 UTC
(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.
Comment 17 m.loikasek 2014-11-10 16:42:34 UTC
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.
Comment 18 e 2015-01-02 16:36:55 UTC
Bug continues to still exist and can confirm frustration. Linux Mint, Calc Version:4.2.7.2
Comment 19 raal 2015-03-20 08:58:50 UTC
*** Bug 90123 has been marked as a duplicate of this bug. ***
Comment 20 dm04 2015-03-20 09:45:42 UTC
this bug is still there in 4.1.4.2, 4.2 and 4.3.6 both on Windows x86 and Linux x64
Comment 21 Larry Bradley 2015-08-31 00:03:17 UTC Comment hidden (obsolete)
Comment 22 Larry Bradley 2015-08-31 00:07:23 UTC
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.
Comment 23 raal 2015-09-12 06:17:42 UTC Comment hidden (obsolete)
Comment 24 raal 2015-09-12 06:17:52 UTC
*** Bug 93852 has been marked as a duplicate of this bug. ***
Comment 25 web_libreoffice 2015-11-16 12:30:40 UTC
Bug still there, after over 2 years from original report, tested by me in 5.0.2.2 on Linux 64bit.
Comment 26 Robinson Tryon (qubit) 2015-12-14 05:32:39 UTC Comment hidden (obsolete)
Comment 27 David 2016-02-12 00:22:39 UTC
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.
Comment 28 Peter Draganov 2016-02-12 06:32:53 UTC
As you can see in Comment 3, 4.0.4 was OK.
Comment 29 Xisco Faulí 2016-10-06 13:36:18 UTC
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
Comment 30 Armin Le Grand 2016-10-07 08:37:46 UTC
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.
Comment 31 Buovjaga 2016-11-24 08:42:42 UTC
*** Bug 103887 has been marked as a duplicate of this bug. ***
Comment 32 Buovjaga 2017-02-24 17:46:35 UTC
*** Bug 83065 has been marked as a duplicate of this bug. ***
Comment 33 Yousuf Philips (jay) (retired) 2017-06-10 23:53:27 UTC
*** Bug 108451 has been marked as a duplicate of this bug. ***
Comment 34 QA Administrators 2018-06-11 02:34:14 UTC Comment hidden (obsolete)
Comment 35 Peter Draganov 2018-06-11 06:38:59 UTC
The bug is still present in Windows version: 6.0.4.2 (x64)
Comment 36 Telesto 2018-09-09 09:11:27 UTC
*** Bug 119763 has been marked as a duplicate of this bug. ***
Comment 37 David 2018-09-09 16:59:20 UTC Comment hidden (obsolete)
Comment 38 David 2018-09-09 17:48:06 UTC Comment hidden (obsolete)
Comment 39 QA Administrators 2019-12-10 04:05:40 UTC Comment hidden (obsolete)
Comment 40 David 2019-12-10 06:20:05 UTC Comment hidden (obsolete)
Comment 41 David 2019-12-10 06:36:28 UTC Comment hidden (obsolete)
Comment 42 David 2019-12-10 06:57:28 UTC Comment hidden (obsolete)
Comment 43 Peter Draganov 2019-12-10 08:49:28 UTC
I can confirm that the bug still exists in 6.2.8.2-2.fc30
Comment 44 Xisco Faulí 2020-05-22 10:34:08 UTC
*** Bug 133255 has been marked as a duplicate of this bug. ***
Comment 45 joe 2020-05-23 01:52:12 UTC
Thanks!

This is still present in 7.0 alpha FYI...
Comment 46 steve 2020-06-04 23:29:48 UTC
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.
Comment 47 David 2020-06-05 03:58:00 UTC
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.
Comment 48 David 2020-06-05 04:07:49 UTC Comment hidden (obsolete)
Comment 49 David 2020-06-05 05:00:53 UTC Comment hidden (obsolete)
Comment 50 Tomaz Vajngerl 2020-06-05 07:09:37 UTC Comment hidden (obsolete)
Comment 51 David 2020-06-05 07:42:31 UTC Comment hidden (obsolete)
Comment 52 Telesto 2020-06-05 08:12:38 UTC Comment hidden (obsolete)
Comment 53 Timur 2020-06-05 08:53:47 UTC
(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.
Comment 54 David 2020-06-05 09:08:16 UTC Comment hidden (obsolete)
Comment 55 David 2020-06-05 09:09:08 UTC Comment hidden (obsolete)
Comment 56 David 2020-06-05 09:14:57 UTC
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.)
Comment 57 David 2020-06-05 09:34:11 UTC
*** Bug 133696 has been marked as a duplicate of this bug. ***
Comment 58 Timur 2020-06-05 12:16:55 UTC
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.
Comment 59 Daniel 2020-06-06 10:41:32 UTC
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
Comment 60 steve 2020-06-06 11:01:23 UTC
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.
Comment 61 Dan Dascalescu 2020-09-17 07:08:18 UTC
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.
Comment 62 Dan Dascalescu 2020-09-17 07:10:30 UTC
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.
Comment 63 Dan Dascalescu 2020-09-17 07:12:07 UTC
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.
Comment 64 Xisco Faulí 2020-11-18 12:06:56 UTC
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
Comment 65 Timur 2021-03-22 17:05:17 UTC
*** Bug 141150 has been marked as a duplicate of this bug. ***
Comment 66 Timur 2021-07-22 14:00:47 UTC
*** Bug 143492 has been marked as a duplicate of this bug. ***
Comment 67 Armin Le Grand 2022-01-05 10:04:00 UTC
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.
Comment 68 Jean-Baptiste Faure 2022-02-03 16:56:12 UTC
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
Comment 69 Timur 2022-02-04 11:22:57 UTC
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.
Comment 70 Jean-Baptiste Faure 2022-02-04 15:57:03 UTC
(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
Comment 71 larrybradley 2022-02-04 21:11:05 UTC
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.
Comment 72 David 2022-02-04 21:37:02 UTC
@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.
Comment 73 larrybradley 2022-02-04 21:59:59 UTC
(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.
Comment 74 Jeff Fortin Tam 2022-02-04 22:30:53 UTC
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?
Comment 75 David 2022-02-05 01:05:45 UTC
(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.
Comment 76 larrybradley 2022-02-05 01:40:58 UTC
(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.
Comment 77 Timur 2022-04-26 19:46:31 UTC
*** Bug 148804 has been marked as a duplicate of this bug. ***