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 (view as bug list)
Depends on:
Blocks: Calc-Comments
  Show dependency treegraph
 
Reported: 2013-08-29 07:50 UTC by Peter Draganov
Modified: 2020-09-17 07:12 UTC (History)
22 users (show)

See Also:
Crash report or crash signature:


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 spam 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 spam 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.