Description: The so-called text tearing bug seems to be a side effect of having the View>Sidebar option checked, regardless of whether or not the sidebar is maximized, in minimized tab view, or hidden (a tiny sliver of it is still there to indicate the left-pointing Show arrow alongside the vertical scroll bar that’s used to expand the sidebar). There is an exception to this and that is if the sidebar is docked to the left-hand side of the monitor screen, then the bug no longer manifests itself. I say so-called text tearing bug because that is only one symptom of this particular bug. There are times when the text does indeed seem to tear across either an entire line of text as you are scrolling up/down through a document or just a highlighted section of text when using the Clone Formatting tool, but more often than not the issue is that the lines of text shrink in height (sometimes only marginally, sometimes rather significantly). Note: Some users may NOT notice this bug because they are using 100% screen layout view. The bug is far more noticeable if using the Fit Width or Optimal Zoom Factor settings, as the problem is thus magnified. Also, some shorter documents do not seem to ever demonstrate the above mentioned symptoms. Also of importance in replicating the bug is that you do NOT actually have to see the text tearing or font shrinkage to know it is there. The tell-tale sign of the bug is line shifting, which you can easily see and verify for yourself by scrolling down a document to a point, then Toggle Automatic Spell Checking. Of course the red and blue squiggly lines indicating a spelling or grammatical error will come and go, but the text lines should be rock solid, but if they shift up or down even slightly—then you are experiencing the bug. So, the short-term, band-aid "fix" is to deselect the View>Sidebar option (Ctrl+F5) until someone delves into the source code for a permanent fix. Steps to Reproduce: 1. Select a long, heavily formatted document (headers, lists, tables, etc.) 2. Either select text for formatting, scroll vertically, or toggle automatic spell checking after scrolling (first two in particular are intermittent) Actual Results: Text tearing while selecting text, font shrinkage after scrolling, and line shifting when toggling automatic spell checking. Expected Results: No text tearing, font shrinkage, or line shifting during use. Reproducible: Sometimes User Profile Reset: Yes Additional Info: Version: 7.1.2.2 (x64) / LibreOffice Community Build ID: 8a45595d069ef5570103caea1b71cc9d82b2aae4 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
With regards to my initial bug post, which I tried to keep as concise and to the point as possible, there are a couple of things I thought went without saying but perhaps should have been explicitly stated for completeness. One, since I maintain that the three issues this bug causes are all seemingly related to the sidebar being docked to the right-hand side of the monitor screen—but not to the left-hand side, then undocking the sidebar and leaving it to float is also a “solution”. However, it is doubtful that either of those “solutions” would be something any user would do because, in the former case, there already is an apparently unmovable media sidebar located there and, in the latter case, due to the sheer size and shape of the “sidebar”, having it floating is not a viable solution as it would block too much of the workspace. Two, since having no sidebar on the right-hand side of the monitor screen is a “solution”, then changing the view from Normal to Web or Full Screen are also “solutions.” Again, it is doubtful that many users would use the Web view because the margins are, at least for me, annoyingly too close to the edges of the screen for easy reading (at least with larger font sizes) and the Full Screen view lacks title and menu bars that users might want access to (unless you happen to know all the shortcuts off the top of your head). So, the best temporary “solution” would seem to be to deselect the Sidebar option from the View drop-down menu and, if you need the functionality of the Navigator, for example, then access it via the View drop-down menu until a permanent software solution is found.
Thanks for reporting this issue. Could you please attach a screenshot of the problem ?
(In reply to Xisco Faulí from comment #2) > Thanks for reporting this issue. > Could you please attach a screenshot of the problem ? The line shifting cannot be captured in a screenshot because it's transitory, so only a video would be able to show the lines shifting vertically. The other symptoms have been written up a number of times in the past as text tearing, although that term does not adequately encompass the three related issues. Since those other two issues are intermittent, it's best to work on the line shifting issue because it's much easier to replicate.
It appears nobody has yet taken an interest in finding the cause of these three related issues I described above. Not using the sidebar seemingly eliminates the text tearing issue and greatly reduces the occurrences of, and minimizes the severity of, the font shrinkage and line shifting issues. I have also noticed that deselecting the Toggle Automatic Spell Check before scrolling a document seems to at the very least minimize, if not eliminate, the font shrinkage and line shifting issues. So, the combination of the two (not using the sidebar and not scrolling with the Toggle Automatic Spell Check selected) seems to be an effective band aid for these pesky problems. Based on my Bugzilla readings, it seems that LibreOffice uses the int data type instead of the double type, which would seemingly be the root cause of this flaky behavior. I have not been able to figure out how to download the source code into Code::Blocks so I can view it and possibly do the debugging myself. Any easy-to-follow, step-by-step process would be appreciated, as once I get access to the source code, I should be able to fix this bug myself.
Setting to UNCONFIRMED, because lack of reproducer.. Everything described here exist. However kind of complicated to find easy system independent reproducers; I did few attempts left & right: like bug 144862 And see also the "see also' section at bug 140161. You might find bug 103322 interesting.. Related to the source code. Starting point would be https://wiki.documentfoundation.org/Development Not sure how good/bad the documentation is at this point in time.
Line shifting part should be gone with latest Master build.
I could reproduce the lines moving when turning Automatic Spell Checking on and off after scrolling, but I found it unrelated to if the sidebar was showing or not. Version: 7.4.2.3 (x64) / LibreOffice Community Build ID: 382eef1f22670f7f4118c8c2dd222ec7ad009daf CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: threaded However, I can't see it anymore in the latest master build: Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 0eec6d44c65f895c6fe2172792717418627db05d CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: threaded The related Bug 149322 was recently fixed (for LibreOffice 7.4.4 and 7.5). Could you please test to see if you can still see the issue you describe, using a recent development build available here: https://dev-builds.libreoffice.org/daily/master/current.html Thank you!
Dear Eek! A Bug. Kill it!, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear Eek! A Bug. Kill it!, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp