Created attachment 67429 [details] screenshot comment text if i set the first ROW of my worksheet as header line (menu WINDOW / FREEZE), comment text in first row cell becomes invisible if larger than comment window Steps to reproduce: 1. open empty spreadsheet 2. define first row as header row (menu WINDOW / FREEZE) 3. insert comment in first row cell (right click "insert comment") 4. write some comment text that is longer than the comment window, the part of the text that is longer will not break to second comment line but becomes invsible. This only happens when the first row is frozen (menu WINDOW / FREEZE) *******CHECK SCREENSHOT ATTACHED******
Hello What I reproduce: 1. File> New> Spreadsheet 2. In A1 Insert>Comment, Type "Comment text long enouth to cause line breaks" 3. Right Click on A1> Show Comment 4. Select A2 5. Window> Freeze 6. Double click in the comment on "Comment" Expected result: edit the comment, see the all text Actual result: edit the comment, only the first line is visible 7. Click outside the comment to quit edit mode 8. Double click in the comment on the last word "breaks" Expected & actual result: edit the comment, see the all text The following may not be a bug: 1. File> New> Spreadsheet 2. In A1 Insert>Comment, Type "Comment text long enouth to cause line breaks" 3. Right Click on A1> Show Comment 4. Select A2 5. Window> Freeze 6. Scroll down (mouse wheel or vertical scroll bar) Only the first line of the comment remains visible... Platform: Version 3.6.2.1 (Build ID: ba822cc) & Windows 7 64bits Regards Pierre-Yves
OK. try it with freezing the first line FIRST (from A2 window / freeze), then add a comment to cell A1. In my interpretation this is a bug, since it works when the first line is not "frozen". rgds tom
(In reply to comment #2) > OK. try it with freezing the first line FIRST (from A2 window / freeze), then > add a comment to cell A1. Ok I understand now... Probably two effects of the same bug when entering and when editing. Steps to reproduce: 1. File> New> Spreadsheet 2. Select A2 3. Window> Freeze 4. Select A1 5. Insert>Comment, Type "Comment text long enouth to cause line breaks" Expected result: the text must remain visible when it passes the line. Actual result: the text after the newline is invisible when entering (becomes visible when you click outside the comment) See ScreenshotStep5 (text after the newline is invisible) Regards Pierre-Yves
Created attachment 67493 [details] ScreenshotStep5
I can confirm bug in LibreOffice 4.0.2.2. I have never seen any version on Windows, Linux or Mac OS X where this doesn't happen.
*** Bug 56619 has been marked as a duplicate of this bug. ***
Confirmed 4.1.4.2 Linux
Ubuntu 14.04 LibreOffice 4.4 beta 2 - I see the issue LibreOffice 3.3 (inherited from OOo) - I do not see the issue. Changing: Priority: Minor - can slow down professional work but will not prevent it. Medium - looks like a regression so bumped up from low. Keyword: Regression Cannot bibisect (all are bad) so version is preBibisect. One other note that might be relevant for fixing: With 3.3 the font text is always black in comments, in all the bad ones, the font text follows the system colors set in tools-> options -> appearance. I'm not sure if these are related but I noticed it.
While it's possible the behaviour on Linux is different, I can confirm this on OSX with LO 3.3.0. I think on balance this isn't a regression Setting: Version -> Inherited from OOo Removing: Keywords: regression
** 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.5 or 5.1.0) 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: 2016-02-21
I have checked in Version: 5.1.3.2 (x64) on Windows 7 Pro; hidden text bug has disappeared, but remains next annoying behaviour: - part of the frozen line cell's comment overlapped with no-frozen cells disappears when no frozen cells are scrolled, remaining visible only frozen line overlapped part of the comment. - part of the NO-frozen line cell's comment overlapped with FROZEN cells remains when no frozen cell is scrolled. I cannot decide if old bug has been corrected and I must open a new bug, remain in the same bug or if described behaviour is not a bug. Please, take your decision as developers, and it will be good for me. Regards.
*** Bug 102314 has been marked as a duplicate of this bug. ***
*** Bug 108647 has been marked as a duplicate of this bug. ***
*** Bug 118061 has been marked as a duplicate of this bug. ***
Dear th, 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
*** Bug 126847 has been marked as a duplicate of this bug. ***
I submitted a bug (126487) and had it rejected as a duplicate of 55133. Fair enough. But: Bug 55133 seems to have prevailed in release 5.1.3.2 and it still prevails in release 6.3.0.4 (x64). So, it seems to me that the bug has gone underground. In case my bug report has been lost as a result of rejection I will re-quote my report here: Description: I added a largish comment to a cell in the first row so it is in a box which is taller than the row's height. I froze the first row. When I scroll down I can hover over the comment and it is displayed correctly. However: If I set the comment to "Show" and scroll so the sheet goes up (scroll down), the part of the comment which is below the first row goes up with the rest of the sheet. Steps to Reproduce: 1. Start a new spread sheet 2. Right click row 2 and select "Freeze Rows and Columns" 3. Right click cell A1 and select "Insert Comment" and paste the following in to the comment box: This is a long comment which goes over more than one row 4. Left click cell A1 to make the comment hide itself At this stage scrolling the sheet up and hovering over the comment marker works fine; BUT: 5. Right click cell A1 and select "Show Comment" At this stage scrolling the sheet up scrolls the bottom half of the comment up as well so that you can only see: This is a long Actual Results: Truncated "shown comment" on scrolling Expected Results: We should be able to view the whole comment on a frozen row when the sheet is scrolled up Reproducible: Always User Profile Reset: No Additional Info: Version: 6.3.0.4 (x64) Build ID: 057fc023c990d676a43019934386b85b21a9ee99 CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; Locale: en-GB (en_GB); UI-Language: en-US Calc: threaded
Sorry, I quoted my bug number incorrectly it should be 126847 not 126487.
Changing priority to 'high' since the number of duplicates is higher than 5 or the number of people in CC higher than 20
Works for me Version: 7.5.2.2 (X86_64) / LibreOffice Community Build ID: 53bb9681a964705cf672590721dbc85eb4d0c3a2 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d408e940630d131ab886a1d4619671fa0299c03e CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Jumbo
(In reply to m.a.riosv from comment #21) > Works for me Then comment 17 should be converted into a new bug report, because that behavior is still relevant.
Before closing bug, it is always good to test NOK some version and then to test OK and say WFM. Here, if someone else can test to confirm, please do.
(In reply to ady from comment #22) > Then comment 17 should be converted into a new bug report, because that > behavior is still relevant. Bug 126847 is now no longer duplicate of this bug 55133.
This was really closed too soon. When closing, duplicates need to be checked. Bug 56619 is still reproducible.