https://bugs.documentfoundation.org/show_bug.cgi?id=163512
--- Comment #15 from ady <[email protected]> --- I did not say that the horizontal width is automatically modified. By default, there are 2 default widths, one for "edit" (and for "show"), and another for "hover". When editing the content of a comment, the width is kept; only the height is automatically expanded. When the content of the comment is reduced during a follow-up edition, the size of the comment box (both width and height) will be kept. IOW, edition of the content will only automatically expand the height of the comment box; there is no automatic reduction of the height, nor a modification of the width. Whichever the height of the comment box after editing, it will also be kept for the "hover" size. OTOH, for several years now, the initial "hover" width will be wider than the initial "edit" width. Going back to editing the content of the comment, the "edit" width is still as it initially was when the comment was initially created (if there was no manual modification of its size). After the creation of the comment, you can set the comment to "show", modify its width (and its height), and hide the comment again. This used to affect also the "hover" width. Unfortunately, it is no longer the case; the "hover" width is not modified according to the manually-set width. I could understand the temptation of matching the widths, but I do not agree with the idea that the initial default "hover" width should match the narrower default "edit" width. OTOH, I would agree that the user should be able to (somehow) manually set a "hover" width other than the current default, considering that the size of the comment box can be manually set for the other statuses ("edit" and "show"). Comment boxes that are "too narrow" containing "long" text are uncomfortable to read, and they have problems / bugs in freeze panes. Under typical circumstances, there is more horizontal space available for reading than there is vertical space (which causes the problem with freeze panes to be more frequent). The current initial default "edit" width is fine for short text. That's the reason for the narrow default "edit" (and "show") width. Since the "hover" status is only temporal, reading the content of a comment on a wider box is usually more comfortable (and has less conflicts with freeze panes). As for the conflict between comments and other artifacts (such as a Push Button), the width of each of those can be inadequate, or not, depending on several factors such as location. Trying to solve that conflict by modifying the default width of comments should not be taken as a solution, as whichever the width, there could still be similar conflicts; it will depend on the specific layout. Additionally, you can still manually set a different width for the comment when it is set to "show", and for the other artifact (Push Button) too. The conflict between the hovering comment box and the Push Button should be solved appropriately, instead of using a doubtful workaround that has other implications, unrelated to the specific use-case, and that will not really solve the case in a generic way; it will only match specific layouts, just different than the current ones. There might be some "foreground" or similar setting for the comment (see "Arrange") or for the Push Button, or some other method, but it is unrelated to the default width of comment boxes. -- You are receiving this mail because: You are the assignee for the bug.
